home *** CD-ROM | disk | FTP | other *** search
/ IRIX Installation Tools & Overlays 2001 May / SGI IRIX Installation Tools & Overlays 2001 May - Disc 3.iso / relnotes / performer_eoe / ch5.z / ch5
Text File  |  2001-04-16  |  163KB  |  3,829 lines
  1.  
  2.  
  3.  
  4.                                   - 1 -
  5.  
  6.  
  7.  
  8.        6.  _C_h_a_n_g_e_s__f_r_o_m__P_r_e_v_i_o_u_s__R_e_l_e_a_s_e_s
  9.  
  10.        This Chapter identifies incremental changes and enhancements
  11.        since IRIS Performer 2.0.  Changes are presented in reverse
  12.        chronological order, with the most recent releases listed
  13.        first.
  14.  
  15.  
  16.        6.1  _C_h_a_n_g_e_s__i_n__O_p_e_n_G_L__P_e_r_f_o_r_m_e_r__2_._4_._1
  17.  
  18.        6.1.1  _P_r_o_b_l_e_m_s__f_i_x_e_d__i_n__O_p_e_n_G_L__P_e_r_f_o_r_m_e_r__2_._4_._1
  19.  
  20.           +o Intersection testing was limited to geosets with fewer
  21.             than 2^16 triangles.  This limit has been increased to
  22.             2^32 (no SCR number).
  23.  
  24.           +o A successful intersection with an indexed triangle
  25.             strip geoset did not fill the 'prim' field of pfHit.
  26.             This has been fixed (SCR 816478).
  27.  
  28.           +o Intersections and picking with an off-axis viewing
  29.             frustum was not functional.  This has been fixed, in
  30.             both the 2.4.1 and 2.2.12 versions (SCR 803898).
  31.  
  32.           +o Intersection testing with pfDoubleDCS, pfDoubleSCS, or
  33.             pfDoubleFCS nodes was not implemented in Performer 2.4.
  34.             A limited fix has been made, in which single-precision
  35.             versions of the matrices are used for the intersection
  36.             test (no SCR number).
  37.  
  38.           +o DSO IVERSION identifiers specified by Performer had an
  39.             invalid format, sgiX.Y.ABC.  The proper format is
  40.             sgiX.Y.  This could cause applications using the
  41.             backwards-compatibility libraries to fail and has been
  42.             fixed (SCR 816478).
  43.  
  44.           +o Calling pfGetChanESky() before defining a pfEarthSky
  45.             could cause a crash.  This has been fixed (no SCR
  46.             number).
  47.  
  48.           +o Calling pfGetCurLights() before defining any lights
  49.             could cause a crash.  This has been fixed (no SCR
  50.             number).
  51.  
  52.  
  53.        6.1.2  _N_e_w__f_e_a_t_u_r_e_s__a_n_d__i_m_p_r_o_v_e_m_e_n_t_s__i_n__2_._4_._1
  54.  
  55.        6.1.2.1  _p_f_V_o_l_F_o_g
  56.        OpenGL Performer 2.4.1 extends the algorithm for rendering
  57.        layered fog by incorporating self-shadowing and scene
  58.        shadowing. The lower parts of a dense fog or objects below a
  59.  
  60.  
  61.  
  62.  
  63.  
  64.  
  65.  
  66.  
  67.  
  68.  
  69.  
  70.                                   - 2 -
  71.  
  72.  
  73.  
  74.        dense fog then appear darker.
  75.  
  76.        Self-shadowing is enabled by setting flag 0x40 to 1.  The
  77.        fog mode should be set to PFVFOG_EXP.  If the fog has
  78.        different colors at different elevations and the flag 0x0100
  79.        is set to 1 a secondary scattering of light is approximated.
  80.        In this case the color of higher layers may affect the color
  81.        of lower layers.  If the flag 0x80 is set the scene objects
  82.        below a dense fog become darker.  In all these effects the
  83.        light is assumed to come from the top.
  84.  
  85.  
  86.        6.2  _D_i_f_f_e_r_e_n_c_e_s _b_e_t_w_e_e_n _O_p_e_n_G_L _P_e_r_f_o_r_m_e_r _2._4 _a_n_d _I_R_I_S
  87.             _P_e_r_f_o_r_m_e_r _2._2
  88.  
  89.  
  90.  
  91.        6.2.1  _B_e_h_a_v_i_o_r_/_A_P_I__c_h_a_n_g_e_s
  92.  
  93.  
  94.        6.2.1.1  _I_R_I_S__G_L
  95.        OpenGL Performer 2.4 supports OpenGL-based rendering only.
  96.        IRIS GL is no longer supported.  Accordingly, the library
  97.        DSO naming scheme has been changed.  What was previously
  98.        _l_i_b_p_f__o_g_l._s_o (for example) is now simply _l_i_b_p_f._s_o.  Be
  99.        certain to update your Makefiles.
  100.  
  101.  
  102.        6.2.1.2  _p_f_d_u_._h__s_t_r_u_c_t_u_r_e_s_:__p_f_d_G_e_o_m_,__p_f_d_P_r_i_m
  103.        OpenGL Performer 2.4 changes the structure of pfdPrim and
  104.        pfdGeom in order to support multi-texture. Existing code
  105.        using the prior version of these structures must be ported.
  106.        The struct elements tbind, texCoords, texCoordList,
  107.        itexCoords are now arrays of size PF_MAX_TEXTURES.
  108.  
  109.        Porting existing code, the struct members tbind, texCoords,
  110.        texCoordList, itexCoords should be replaced by tbind[0],
  111.        texCoords[0], texCoordList[0], itexCoords[0].
  112.  
  113.        When initializing a pfdPrim struct or when creating a
  114.        pfdGeom struct without the function pfdNewGeom, one must
  115.        initialize the entire array tbind[] to PFGS_OFF as in the
  116.        code example:
  117.  
  118.            {{{{
  119.                iiiinnnntttt        tttt;;;;
  120.                ppppffffddddPPPPrrrriiiimmmm    ****pppp;;;; ////**** OOOOrrrr:::: ppppffffddddGGGGeeeeoooommmm ****pppp;;;; ****////
  121.  
  122.                ffffoooorrrr ((((tttt ==== 0000 ;;;; tttt <<<< PPPPFFFF____MMMMAAAAXXXX____TTTTEEEEXXXXTTTTUUUURRRREEEESSSS ;;;; tttt ++++++++))))
  123.                    pppp---->>>>ttttbbbbiiiinnnndddd[[[[tttt]]]] ==== PPPPFFFFGGGGSSSS____OOOOFFFFFFFF;;;;
  124.            }}}}
  125.  
  126.  
  127.  
  128.  
  129.  
  130.  
  131.  
  132.  
  133.  
  134.  
  135.  
  136.                                   - 3 -
  137.  
  138.  
  139.  
  140.        6.2.1.3  _p_f_F_l_u_x__d_e_f_a_u_l_t__n_u_m_b_e_r__o_f__b_u_f_f_e_r_s_.
  141.        OpenGL Performer 2.4 counts a DBASE process as a pfFlux
  142.        client. Forking a DBASE process increases the default number
  143.        of buffers on a pfFlux by one. Previous versions of OpenGL
  144.        Performer ignored the DBASE process when computing the
  145.        default number of pfFlux buffers.
  146.  
  147.  
  148.        6.2.2  _N_e_w__f_e_a_t_u_r_e_s__a_n_d__i_m_p_r_o_v_e_m_e_n_t_s__i_n__2_._4
  149.  
  150.        6.2.2.1  _E_n_h_a_n_c_e_m_e_n_t_s__t_o__t_h_e__b_a_s_e__l_i_b_r_a_r_y
  151.        OpenGL Performer 2.4 introduces many architectural
  152.        improvements to core features in the library, avoiding API
  153.        changes so as to ensure that very little porting effort will
  154.        be required.  These include:
  155.  
  156.           +o Multipipe scalability enhancements.  A significant
  157.             per-pipe overhead in pfFrame() has been removed. This
  158.             enables making many per-frame scene graph changes even
  159.             when using a high number of graphics pipes.
  160.  
  161.           +o Cliptexture performance enhancements.  The texture
  162.             download algorithm has been enhanced to significantly
  163.             improve texture download speed and the accuracy of DTR
  164.             performance.  Refer to
  165.             /usr/share/Performer/src/sample/C++/clipdemo for an
  166.             example.
  167.  
  168.           +o Ability to lock multiple processes on the same
  169.             processor. Avoids deadlocks that used to occur in some
  170.             priority configurations.
  171.  
  172.           +o Light-point process enhancements.
  173.  
  174.           +o pfFlux is enhanced.  More detailed explanation has been
  175.             added to the Programmer's Guide.
  176.  
  177.           +o Refer to the detailed notes in the 2.2.x section for
  178.             other enhancements since the 2.2 release.
  179.  
  180.  
  181.        6.2.2.2  _E_n_h_a_n_c_e_m_e_n_t_s__t_o__O_p_e_n_G_L__P_e_r_f_o_r_m_e_r__f_o_r__L_i_n_u_x
  182.        Because both the IRIX and Linux versions of OpenGL Performer
  183.        share a common code base and API, as enhancements and new
  184.        features are introduced in the IRIX version, they
  185.        simultaneously become available in Linux, and vice versa.
  186.        In addition many internal enhancements have been made in
  187.        OpenGL Performer for Linux to bring its core functionality
  188.        ever closer to that available in IRIX.  Some of the
  189.        enhancements _s_p_e_c_i_f_i_c to OpenGL Performer 2.4 for Linux
  190.        include:
  191.  
  192.  
  193.  
  194.  
  195.  
  196.  
  197.  
  198.  
  199.  
  200.  
  201.  
  202.                                   - 4 -
  203.  
  204.  
  205.  
  206.           +o Multi-process operation (pfMultiprocess, pfMultithread)
  207.  
  208.           +o Frame-accurate timing control (pfPhase)
  209.  
  210.           +o Anisotropic Texture filtering
  211.  
  212.           +o Multi-Texture support
  213.  
  214.           +o Many performance & feature optimizations, including
  215.             several specific to SGI Linux Desktop workstations.
  216.        These are described in more detail below.
  217.  
  218.  
  219.        6.2.2.3  _N_e_w__f_e_a_t_u_r_e_s__i_n__O_p_e_n_G_L__P_e_r_f_o_r_m_e_r__2_._4
  220.        OpenGL Performer 2.4 includes revolutionary new support for
  221.        sophisticated model shading, enabling users to render higher
  222.        quality scenes far more easily than coding in OpenGL
  223.        directly.  This release also provides several advanced
  224.        visual effects, to better support simulation applications.
  225.        The new features include:
  226.  
  227.  
  228.        6.2.2.3.1  _p_f_S_h_a_d_e_r
  229.        pfShader is a new approach to dramatically simplify OpenGL
  230.        multi-pass rendering creation.  Instead of writing direct
  231.        OpenGL code using pfDraw callbacks and draw bins, users can
  232.        take advantage of the easy to use OpenGL Shader to create
  233.        the same effects at modeling time.
  234.  
  235.        OpenGL Shader is a powerful appearance-modeling tool.  Using
  236.        the Shader language and compiler, users can easily create
  237.        shaders that describe very sophisticated multi-pass
  238.        rendering effects. Read http://www.sgi.com/software/shader/
  239.        for details on OpenGL Shader. The shaders can be associated
  240.        with any pfNode in the OpenGL Performer scene graph to
  241.        achieve high performance multi-passing rendering results
  242.        using OpenGL Performer without writing OpenGL code directly.
  243.  
  244.        pfShader in 2.4 is our first effort at supporting OpenGL
  245.        Shader within OpenGL Performer. The purpose is to establish
  246.        the architecture foundation for this revolutionary approach.
  247.        There are still many limitations in the pfShader.  Not all
  248.        shaders created from OpenGL Shader can be supported in 2.4,
  249.        for example, shaders with variable changes.  Further
  250.        extensions and performance enhancements will become
  251.        available in future regular releases.
  252.  
  253.        Man pages to see: pfShader, pfShaderManager
  254.  
  255.        Sample programs to check out:
  256.  
  257.  
  258.  
  259.  
  260.  
  261.  
  262.  
  263.  
  264.  
  265.  
  266.  
  267.  
  268.                                   - 5 -
  269.  
  270.  
  271.  
  272.                /usr/share/Performer/src/pguide/libpf/C++/shader_blue_and_purple.C
  273.                /usr/share/Performer/src/pguide/libpf/C++/shader_multiple_shaders.C
  274.                /usr/share/Performer/src/pguide/libpf/C++/shader_multiple_shaders.C
  275.                /usr/share/Performer/src/pguide/libpf/C++/shader_red_material.C
  276.                /usr/share/Performer/src/pguide/libpf/C++/shader_test.C
  277.                /usr/share/Performer/src/pguide/libpf/C++/shader_wood_texture.C
  278.  
  279.        Utilities to use:
  280.  
  281.                /usr/share/Performer/src/tools/ipf2pf (convert
  282.        shader file into pfShader file)
  283.                /usr/share/Performer/src/lib/libpfdb/libpfpfs
  284.                /usr/share/Performer/src/lib/libpfdb/libpfpfb
  285.  
  286.        Documentation to use in addtion to Programmer's Guide:
  287.                /usr/share/Performer/src/tools/pfshader_file_spec.txt
  288.  
  289.        pfShader Data:
  290.  
  291.                /usr/share/Performer/data/shaderExample.pfb
  292.                /usr/share/Performer/data/shaders/*.shader
  293.  
  294.  
  295.        6.2.2.3.2  _M_u_l_t_i-_p_r_o_c_e_s_s _o_p_e_r_a_t_i_o_n _i_n _L_i_n_u_x (_F_U_L_L _E_D_I_T_I_O_N
  296.        _o_n_l_y)
  297.        OpenGL Performer 2.4 for Linux now supports the complete
  298.        App/Cull/Draw/Isect/Compute/Dbase/Input multiprocessing
  299.        capabilities of OpenGL Performer for IRIX.  Likewise, the
  300.        underlying IRIX shared arena, locks, and IPC management
  301.        routines such as ussetlock(), usunsetlock() are available
  302.        for developer application through /usr/include/ulocks.h.
  303.  
  304.  
  305.        6.2.2.3.3  _F_r_a_m_e_-_a_c_c_u_r_a_t_e__t_i_m_i_n_g__c_o_n_t_r_o_l__i_n__L_i_n_u_x
  306.        OpenGL Performer 2.4 for Linux now supports the complete
  307.        FREE_RUN/LIMIT/FLOAT/LOCK pfPhase() functionality of OpenGL
  308.        Performer for IRIX.  Note that phase control is currently
  309.        implemented as an emulation timing layer which does not yet
  310.        support swapbuffer synchronization to the vertical retrace;
  311.        If your graphics card currently supports synchronization to
  312.        vertical retrace, Phase control may be off by one video
  313.        field.  This will be corrected as OpenGL driver improvements
  314.        allow.
  315.  
  316.  
  317.        6.2.2.3.4  _M_u_l_t_i_-_t_e_x_t_u_r_e
  318.        OpenGL Performer 2.4 supports the application of multiple
  319.        texture maps on a single polygon using the OpenGL multi-
  320.        texture extension.  Currently, this feature is only
  321.        available in OpenGL Performer for Linux.  pfGeoSet now
  322.        accepts multiple texture coordinate arrays, and pfGeoState
  323.  
  324.  
  325.  
  326.  
  327.  
  328.  
  329.  
  330.  
  331.  
  332.  
  333.  
  334.                                   - 6 -
  335.  
  336.  
  337.  
  338.        now accepts multiple pfTexture, pfTexGen, pfTexLOD, texture
  339.        matrices and detail textures.  The API additions are very
  340.        straightforward.
  341.  
  342.        Man pages to see: pfGeoSet, pfGeoState
  343.  
  344.        Sample programs to check out:
  345.  
  346.                /usr/share/Performer/src/pguide/libpf/C/multiTexBox.c
  347.                /usr/share/Performer/src/pguide/libpf/C/multiTexBox_flux.c
  348.  
  349.        Utilities to use:
  350.  
  351.                /usr/share/Performer/src/lib/libpfdu/pfdBuilder.c
  352.                /usr/share/Performer/src/lib/libpfdu/pfdTMesher.c
  353.                /usr/share/Performer/src/lib/libpfutil/hash.c
  354.                /usr/share/Performer/src/lib/libpfdu/pfdGeoBuilder.c
  355.                /usr/share/Performer/src/lib/libpfdu/pfdRebuild.c
  356.  
  357.        Loaders that support multi-texture data: Flight loader, pfb
  358.        loader
  359.  
  360.  
  361.        6.2.2.3.5  _A_n_i_s_o_t_r_o_p_i_c__f_i_l_t_e_r
  362.        Standard mipmap filtering can induce blurring on a texture
  363.        if the texture is applied to a polygon which is angled away
  364.        from the viewer.  To reduce this blurring, an anisotropic
  365.        filter can be used to improve visual quality.  The
  366.        anisotropic filter is only available on Linux systems.
  367.  
  368.        Man pages to see: pfTexture
  369.  
  370.        Sample programs to check out:
  371.  
  372.                /usr/share/Performer/src/pguide/libpf/C/anisotropic.c
  373.                /usr/share/Performer/src/pguide/libpf/C++/anisotropic.C
  374.  
  375.  
  376.        6.2.2.3.6  _V_o_l_u_m_e__f_o_g
  377.        pfVolFog is a new class that uses a multi-pass algorithm to
  378.        draw the scene with fog that has different densities at
  379.        different locations. It extends the basic layered fog
  380.        provided by pfEarthSky and it supports two types of fog:
  381.        layered fog and patchy fog.
  382.  
  383.        Layered fog changes only with elevation, its density and
  384.        color is uniform at a given height. It is defined by a set
  385.        of elevation points, each specifying a fog density and
  386.        optionally also a fog color at the point's elevation.  The
  387.        density and the color between two neighboring points is
  388.        linearly interpolated.  Patchy fog has a constant density in
  389.  
  390.  
  391.  
  392.  
  393.  
  394.  
  395.  
  396.  
  397.  
  398.  
  399.  
  400.                                   - 7 -
  401.  
  402.  
  403.  
  404.        a given area. The boundaries of this area can be defined by
  405.        an arbitrary three-dimensional object or a set of objects.
  406.  
  407.        Man pages to see: pfVolFog
  408.  
  409.        Demos to check out:
  410.  
  411.                /usr/share/Performer/src/sample/C++/volfog
  412.                /usr/share/Performer/src/sample/C/fogfly
  413.  
  414.  
  415.        6.2.2.3.7  _R_o_t_o_r__W_a_s_h
  416.        A pfRotorwash is used to create a graph including geometry
  417.        and pfState which represents the visual downwash effect on
  418.        terrain or water. The geometry changes dynamically with the
  419.        scene and position from which it is generated. Users who are
  420.        developing helicopter demos are especially encouraged to try
  421.        out this feature.
  422.  
  423.        Man pages to see: pfRotorwash
  424.  
  425.        Demos to check out:
  426.  
  427.                /usr/share/Performer/src/sample/C++/rotorwash
  428.  
  429.  
  430.        6.2.2.3.8  _D_o_u_b_l_e__p_r_e_c_i_s_i_o_n__m_a_t_r_i_x__s_u_p_p_o_r_t  Double precision
  431.        matrix operations are supported in this release. This
  432.        feature is extremely helpful when rendering large databases
  433.        where objects can be very far away from the origin.
  434.  
  435.        Man pages to see: pfDoubleDCS, pfDoubleFCS, pfDoubleSCS
  436.  
  437.        Sample programs to check out:
  438.  
  439.                /usr/share/Performer/src/pguide/libpf/C/doubleDCS.c
  440.                /usr/share/Performer/src/pguide/libpf/C/doubleDCS2.c
  441.  
  442.        Demos to check out:
  443.  
  444.                /usr/share/Performer/src/sample/C/clipfly
  445.  
  446.  
  447.        6.2.2.3.9  _A_b_i_l_i_t_y _t_o _l_o_c_k _m_u_l_t_i_p_l_e _p_r_o_c_e_s_s_e_s _o_n _t_h_e _s_a_m_e
  448.        _p_r_o_c_e_s_s_o_r.  OpenGL Performer 2.4 adds new API for
  449.        eliminating frame glitches when locking multiple processes
  450.        on one processor. This API enables a temporary priority
  451.        upgrade for low priority processes when the APP process
  452.        waits for them.
  453.  
  454.        Man pages to see: pfProcessPriorityUpgrade,
  455.  
  456.  
  457.  
  458.  
  459.  
  460.  
  461.  
  462.  
  463.  
  464.  
  465.  
  466.                                   - 8 -
  467.  
  468.  
  469.  
  470.        pfProcessHighestPriority
  471.  
  472.  
  473.        6.2.2.3.10  _D_P_L_E_X__s_u_p_p_o_r_t
  474.        Refer to the description under 2.2.4 for details.
  475.  
  476.  
  477.        6.2.2.3.11  _L_O_D__e_v_a_l_u_a_t_i_o_n__f_u_n_c_t_i_o_n
  478.        pfLOD is extended to take a user function for picking an LOD
  479.        result. The result of this user function is a floating point
  480.        number. This gives users ultimate flexibility in LOD
  481.        evaluation.
  482.  
  483.        Man pages to see: pfLOD
  484.  
  485.  
  486.        6.3  _D_i_f_f_e_r_e_n_c_e__b_e_t_w_e_e_e_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._3__a_n_d__2_._2
  487.  
  488.        IRIS Performer 2.3 was the first release of Performer for
  489.        Linux.  Please refer to the OpenGL Performer website for
  490.        details.
  491.  
  492.  
  493.        6.4  _C_h_a_n_g_e_s__i_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._2_._1_0
  494.  
  495.        6.4.1  _P_r_o_b_l_e_m_s__f_i_x_e_d__i_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._2_._1_0
  496.  
  497.           +o The IRIX PFB file loader was unable to read PFB files
  498.             generated on Linux-based systems due to file
  499.             endianness.  This has been fixed (SCR 786258).
  500.  
  501.           +o Performer serialized the rendering of each pfPipe on
  502.             multi-pipe systems running in "Multi-Keyboard" or "TKO"
  503.             mode.  This has been fixed (SCR 791376).
  504.  
  505.  
  506.        6.5  _C_h_a_n_g_e_s__i_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._2_._9
  507.  
  508.        6.5.1  _P_r_o_b_l_e_m_s__f_i_x_e_d__i_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._2_._9
  509.  
  510.           +o Calligraphic light points flash in certain multipipe
  511.             configurations.  This is the case even in
  512.             PF_LPOINT_BOARD emulation mode.
  513.  
  514.             Each calligraphic board (including the simulated one)
  515.             has some amount of memory which is used to specify
  516.             light points. When performer fills up this memory
  517.             buffer, meaning that the board can not take more input,
  518.             it will render the remaining points in software mode.
  519.             lpoints rendered in software mode occupy more pixels on
  520.             screen than lpoints rendered in hardware mode, hence
  521.  
  522.  
  523.  
  524.  
  525.  
  526.  
  527.  
  528.  
  529.  
  530.  
  531.  
  532.                                   - 9 -
  533.  
  534.  
  535.  
  536.             the flashing behavior. The problem is due to the fact
  537.             that Performer's memory book-keeping for lpoint buffers
  538.             breaks under a couple conditions:
  539.  
  540.             1) When at least one pipe is doing calligraphics but
  541.             pipe 0 is not 2) When calligraphics are used on non-
  542.             consecutive pipes
  543.  
  544.             These memory book-keeping problems have been fixed in
  545.             2.2.9 (SCR 787645).
  546.  
  547.  
  548.  
  549.        6.6  _C_h_a_n_g_e_s__i_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._2_._8
  550.  
  551.        6.6.1  _P_r_o_b_l_e_m_s__f_i_x_e_d__i_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._2_._8
  552.  
  553.           +o Access into Shared Memory pages is slow the first time
  554.             each page is accessed.  This is particularly noticeable
  555.             when paging ClipTextures.  A workaround has been
  556.             implemented (see 'New Features' below).  SCR 606004.
  557.  
  558.           +o pfFindNode/pfLookupNode cannot find a pfGeode with
  559.             pfNode type, though the manpage says that Performer
  560.             uses pfIsOfType instead of pfIsExactType for those
  561.             functions.  This has been fixed so that
  562.             pfNode/pfLookupNode use pfIsOfType instead of
  563.             pfIsExactType semantics (SCR 774905).
  564.  
  565.           +o
  566.  
  567.           +o The pfb loader leaks memory when a texture image file
  568.             is not available. Loading and deleting a model with one
  569.             texture image file missing leaks sizeof(pfTexture)
  570.             bytes.
  571.  
  572.  
  573.        6.6.2  _N_e_w__f_e_a_t_u_r_e_s__i_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._2_._8
  574.  
  575.        6.6.2.1  _A_r_e_n_a__P_a_g_e__E_x_e_r_c_i_s_i_n_g
  576.  
  577.           +o When a forked process accesses memory in the shared
  578.             arena, the first time it accesses each page is much
  579.             slower than accessing that page subsequently. This
  580.             problem becomes very pronounced when the forked process
  581.             is striding through a large number of pages, such as
  582.             sending large amounts of texture from the arena to the
  583.             pipes, as is the case with cliptexturing.  In this
  584.             case, the application will experience performance
  585.             glitches when memory regions are accessed for the first
  586.             time.
  587.  
  588.  
  589.  
  590.  
  591.  
  592.  
  593.  
  594.  
  595.  
  596.  
  597.  
  598.                                   - 10 -
  599.  
  600.  
  601.  
  602.             The workaround for this problem is to access a memory
  603.             location in each page of the arena during program
  604.             startup. This workaround makes most sense in the DRAW
  605.             process, since it's the one that's affected most due to
  606.             its access of large amounts of texture data.
  607.  
  608.             Performer 2.2.8 will touch each arena page in each draw
  609.             process if the environment variable
  610.             "_PFDRAW_EXERCISE_ARENA" is set. If the environment
  611.             variable is set to a numerical value, each draw process
  612.             will run through the arena the specified number of
  613.             times, reporting how long it took to touch all the
  614.             pages in each iteration. It's not necessary to touch
  615.             each page more than once except to see the difference
  616.             in access times to those pages.
  617.  
  618.  
  619.        6.6.2.2  _S_u_p_p_o_r_t__f_o_r__n_e_w__O_c_t_a_n_e__g_r_a_p_h_i_c_s__h_a_r_d_w_a_r_e
  620.  
  621.           +o Performer 2.2.8 introduces support for the new Octane
  622.             graphics hardware. If this hardware is detected,
  623.             Performer will use OpenGL features that are on the fast
  624.             path for this system, just as with other supported
  625.             hardware.
  626.  
  627.  
  628.        6.6.2.3  _P_o_s_t__l_p_o_i_n_t_-_d_r_a_w__c_a_l_l_b_a_c_k
  629.  
  630.           +o Some applications need to draw to the frame buffer
  631.             after all other drawing has occurred. In the case where
  632.             applications uses a forked LPOINT process, the drawing
  633.             of light points happens after the draw callback is
  634.             invoked, making it difficult to draw something on top
  635.             of the light points.
  636.  
  637.             To get around this problem, Performer 2.2.8 now
  638.             supports a post-lpoint-draw callback on pfChannels. To
  639.             add such a callback to a pfChannel, use the
  640.             "PFTRAV_POSTLPOINT" token to pfChannel::setTravFunc or
  641.             pfChanTravFunc, for example:
  642.  
  643.  
  644.             cccchhhhaaaannnnnnnneeeellll---->>>>sssseeeettttTTTTrrrraaaavvvvFFFFuuuunnnncccc((((PPPPFFFFTTTTRRRRAAAAVVVV____PPPPOOOOSSSSTTTTLLLLPPPPOOOOIIIINNNNTTTT,,,, ppppoooossssttttDDDDrrrraaaawwwwFFFFuuuunnnncccc))));;;;
  645.  
  646.             The callback will be invoked regardless of
  647.             multiprocessing mode. In applications which fork the
  648.             LPOINT process, it will be called after the last light
  649.             point has been drawn in each channel. In applications
  650.             which do not fork the LPOINT process, the post-lpoint-
  651.             draw callback will be invoked immediately after the
  652.             draw callback returns. This callback is not reflected
  653.  
  654.  
  655.  
  656.  
  657.  
  658.  
  659.  
  660.  
  661.  
  662.  
  663.  
  664.                                   - 11 -
  665.  
  666.  
  667.  
  668.             in the stats.
  669.  
  670.             Since Performer 2.2.8 is an eoe update, we can not
  671.             distribute header files, so to use the FTRAV_POSTLPOINT
  672.             token, you must define it. Include the following lines
  673.             in files using the token:
  674.  
  675.  
  676.             ####iiiiffffnnnnddddeeeeffff PPPPFFFFTTTTRRRRAAAAVVVV____PPPPOOOOSSSSTTTTLLLLPPPPOOOOIIIINNNNTTTT
  677.             ####ddddeeeeffffiiiinnnneeee PPPPFFFFTTTTRRRRAAAAVVVV____PPPPOOOOSSSSTTTTLLLLPPPPOOOOIIIINNNNTTTT 6666
  678.             ####eeeennnnddddiiiiffff
  679.  
  680.        6.7  _C_h_a_n_g_e_s__i_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._2_._7
  681.  
  682.        6.7.1  _P_r_o_b_l_e_m_s__f_i_x_e_d__i_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._2_._7
  683.  
  684.           +o Triangle fans were not being correctly reported by the
  685.             stats.  This has been fixed (SCR 769104).
  686.  
  687.           +o An array bounds underrun in _pfCuller::pf_applyXform
  688.             could lead to memory corruption.  This has been fixed
  689.             (SCR 767432).
  690.  
  691.           +o The prototype for pfDTRApplyImageCache was incorrectly
  692.             documented.  This has been fixed (SCR 752840).
  693.  
  694.           +o pfNode::bufferClone could cause a segmentation
  695.             violation.  This has been fixed (SCR 695725).
  696.  
  697.           +o The channel frustum type was being reset by
  698.             pfChannel::pf_cullShadows.  This has been fixed (SCR
  699.             679085).
  700.  
  701.           +o A memory leak caused by multi-pipe pfImageCache
  702.             invalidation has been fixed.
  703.  
  704.  
  705.        6.8  _C_h_a_n_g_e_s__i_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._2_._6
  706.  
  707.        6.8.1  _P_r_o_b_l_e_m_s__f_i_x_e_d__i_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._2_._6
  708.  
  709.           +o A change in the semantics of sginap() could cause
  710.             frames to be missed if the application was running in
  711.             FLOAT or LOCK phase and finishing its frame more than a
  712.             full video field early.  See Chapter 4 of these release
  713.             notes for more details.  This has been fixed in IRIX
  714.             6.5.5 (SCR 635983).
  715.  
  716.           +o A math error when in multipass lighting mode caused
  717.             infinite lights (those with a w coordinate of 0) to be
  718.             transformed incorrectly through the modelview matrix,
  719.  
  720.  
  721.  
  722.  
  723.  
  724.  
  725.  
  726.  
  727.  
  728.  
  729.  
  730.                                   - 12 -
  731.  
  732.  
  733.  
  734.             producing incorrect lighting results.  This has been
  735.             fixed.
  736.  
  737.           +o A reversed cross product caused the
  738.             pfLightSource::setSpotDir call to rotate the light in
  739.             the wrong direction in some cases.  This has been
  740.             fixed.
  741.  
  742.        6.8.2  _N_e_w__f_e_a_t_u_r_e_s__i_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._2_._6
  743.  
  744.        6.8.2.1  _M_u_l_t_i_p_a_s_s__L_i_g_h_t_i_n_g
  745.  
  746.           +o The multipass implementation introduced in 2.2.5 did
  747.             not support fog-based range attenuation of projective
  748.             lights.  This feature is now supported.
  749.  
  750.           +o Prior releases cleared the color buffer to red when
  751.             generating the shadow maps for shadow-casting lights.
  752.             Code which assumed that the shadowmap generation pass
  753.             would clear the framebuffer to black produced incorrect
  754.             results, so this behavior has been changed; The color
  755.             buffer is now cleared to black when rendering the
  756.             shadow map.  Note:  No assumptions should be made about
  757.             the contents of the color buffer between shadowmap and
  758.             scene rendering; always clear the color buffer when
  759.             unsure of its contents.
  760.  
  761.  
  762.        6.9  _C_h_a_n_g_e_s__i_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._2_._5
  763.  
  764.        6.9.1  _P_r_o_b_l_e_m_s__f_i_x_e_d__i_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._2_._5
  765.  
  766.           +o pfFrustum::makeOrtho() calculated incorrect near/far
  767.             clip plane values.  This has been fixed (SCR 658920).
  768.  
  769.           +o pfGetStage() could return incorrect values due to the
  770.             Performer clock being included in the process list.
  771.             This has been fixed (SCR 668773).
  772.  
  773.           +o Channel-CULL callbacks registered from the .ct loader
  774.             could collide when used in multi-channel
  775.             configurations, resulting in the incorrect calculations
  776.             of texture coordinates.  This regression has been fixed
  777.             (SCR 668222).
  778.  
  779.           +o perfly, asdfly, and clipfly could not configure multi-
  780.             hyperpipe systems.  This capability has been added (SCR
  781.             675711).
  782.  
  783.           +o Draw statistics were only being accumulated for the
  784.             first pipe in a hyperpipe group.  This has been fixed
  785.  
  786.  
  787.  
  788.  
  789.  
  790.  
  791.  
  792.  
  793.  
  794.  
  795.  
  796.                                   - 13 -
  797.  
  798.  
  799.  
  800.             (SCR 675517).
  801.  
  802.           +o A garbage frame would sometimes be seen when using
  803.             texture from a DIVO source in Performer on Onyx2
  804.             systems with 'Reality' graphics.  This was due to a
  805.             mismatch in Performer's automatic detection of graphics
  806.             type and has been fixed (SCR 671095).
  807.  
  808.           +o The default displacement offset for coplanar polygons
  809.             was set too large for small frusta.  This has been
  810.             fixed (SCR 625598, 670200).  See below for
  811.             configuration details.
  812.  
  813.           +o Several additional improvements to the multipass
  814.             algorithm used for projective texture pfLightSources
  815.             have been made in 2.2.5.  In particular, the algorithm
  816.             now supports geometry with texture based transparency
  817.             (for example, a tree billboard).
  818.  
  819.        6.9.2  _N_e_w__f_e_a_t_u_r_e_s__i_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._2_._5
  820.  
  821.        6.9.2.1  _S_u_p_p_o_r_t__f_o_r__O_p_e_n_G_L__1_._1__g_l_P_o_l_y_g_o_n_O_f_f_s_e_t_(_)
  822.  
  823.        This release modifies the routines used for coplanar polygon
  824.        displacement to one based upon the polygon offset
  825.        functionality in OpenGL 1.1.  The changes apply to all
  826.        platforms using OpenGL 1.1 except the Impact series.
  827.  
  828.        Users may revert to the prior (Performer 2.2) behavior by
  829.        setting the environment variable
  830.        PF_FORCE_EXT_POLYGON_OFFSET.
  831.  
  832.        Likewise, users may choose to force the new functionality to
  833.        be used on Impact systems (despite known bugs at this time)
  834.        by setting the environment variable
  835.        PF_FORCE_ARB_POLYGON_OFFSET.
  836.  
  837.        In case the results of the new offset behavior are not ideal
  838.        for a particular system or database, users may tune the
  839.        values set internally by IRIS Performer.  The environment
  840.        variables PF_ARB_POLYGON_OFFSET_FACTOR and
  841.        PF_ARB_POLYGON_OFFSET_UNITS can be set to floating point
  842.        values which will then be used internally as arguments to
  843.        glPolygonOffset().  See the glPolygonOffset(3G) man page for
  844.        further details of the effect of these settings.
  845.  
  846.        Although the OpenGL 1.1 glPolygonOffset() changes were
  847.        intended to resolve machine dependency issues, please note
  848.        that the ideal offset factor and units value may still vary
  849.        from system to system.  The glPolygonOffset() values set by
  850.        IRIS Performer were chosen for typical database settings on
  851.  
  852.  
  853.  
  854.  
  855.  
  856.  
  857.  
  858.  
  859.  
  860.  
  861.  
  862.                                   - 14 -
  863.  
  864.  
  865.  
  866.        InfiniteReality systems and may require adjustment on other
  867.        OpenGL 1.1 systems, using the environment variables
  868.        described above.
  869.  
  870.  
  871.        6.10  _C_h_a_n_g_e_s__i_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._2_._4
  872.  
  873.        6.10.1  _P_r_o_b_l_e_m_s__f_i_x_e_d__i_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._2_._4
  874.  
  875.           +o The Performer signal handler would enter an infinite
  876.             loop if a process forked or sproc'd from the APP
  877.             process exited.  This has been fixed (SCR 651566).
  878.  
  879.           +o Setting the PF_LPOINT_BOARD environment variable to
  880.             enable emulation of calligraphic hardware (by using
  881.             standard raster light points) had no effect.  This has
  882.             been fixed (SCR 615443).
  883.  
  884.           +o Threading the lightpoint process caused a segmentation
  885.             fault.  This has been fixed.
  886.  
  887.           +o Models containing pfLightPoints with a NULL
  888.             pfLPointState could cause a segmentation violation on
  889.             O2 systems running IRIX 6.5.2.  This has been fixed
  890.             (SCR 614274).
  891.  
  892.           +o Several improvements to the multipass algorithm used
  893.             for projective texture pfLightSources have been made.
  894.             Colored spotlights now interact correctly with each
  895.             other.  Note that the current algorithm does not
  896.             support geometry with texture based transparency (for
  897.             example, a tree billboard), and can only produce
  898.             translucent geometry on systems with multisampling
  899.             capability.
  900.  
  901.           +o Several pfStats::query() tokens were unimplemented.
  902.             Most of the missing tokens can now be used to query
  903.             statistics.  The following will still return an error:
  904.  
  905.                +o PFSTATSVAL_CPU_SECS
  906.                  PFSTATSVAL_CPU_GFX_SWAPBUFFERS
  907.                  PFSTATSVAL_GFXPIPE_TIMES_PERCENTAGE
  908.                  PFSTATSVAL_GFXPIPE_TIMES_PERCENTAGE_HOST
  909.                  PFSTATSVAL_GFXPIPE_TIMES_PERCENTAGE_XFORM
  910.                  PFSTATSVAL_GFXPIPE_TIMES_PERCENTAGE_FILL
  911.                  PFSTATSVAL_GFXPIPE_TIMES_SECS
  912.                  PFSTATSVAL_GFXPIPE_TIMES_SECS_HOST
  913.                  PFSTATSVAL_GFXPIPE_TIMES_SECS_XFORM
  914.                  PFSTATSVAL_GFXPIPE_TIMES_SECS_FILL
  915.  
  916.  
  917.  
  918.  
  919.  
  920.  
  921.  
  922.  
  923.  
  924.  
  925.  
  926.  
  927.  
  928.                                   - 15 -
  929.  
  930.  
  931.  
  932.           +o IRIX 6.5 introduced support for the concurrent use of
  933.             shared arenas and POSIX threads (pthreads), however
  934.             there was an error in the GLX implementation which
  935.             prevented IRIS Performer applications from opening a
  936.             window if the pthread library was linked.  The GLX
  937.             implementation in the IRIX 6.5.3 overlay has addressed
  938.             this problem, so IRIS Performer applications can now be
  939.             safely used with pthreads.
  940.  
  941.           +o The CSB loader has been updated to enable the use of
  942.             ClearCoat(tm).
  943.  
  944.           +o Graphics state information could "leak" from a
  945.             cliptexture to other models in the scene.  This has
  946.             been fixed (SCR 603185).
  947.  
  948.  
  949.        6.10.2  _N_e_w__F_e_a_t_u_r_e_s__i_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._2_._4
  950.  
  951.        6.10.2.1  _S_u_p_p_o_r_t__f_o_r__D_P_L_E_X__o_p_t_i_o_n
  952.  
  953.        Performer 2.2.4 includes support for the DPLEX option to
  954.        Onyx2 Infinite Reality. This support has been affected
  955.        without changes to the API, and modifications to the
  956.        command-line options for perfly, clipfly, and asdfly have
  957.        been made to enable DPLEX. There are, however, some changes
  958.        to the semantics of _p_f_P_i_p_e, _p_f_P_i_p_e_W_i_n_d_o_w, and _p_f_C_h_a_n_n_e_l
  959.        interaction.  This change is described below.
  960.  
  961.        Initialization of the hyperpipe is via the existing
  962.        pfHyperpipe() API.  This call defines the number of _p_f_P_i_p_es
  963.        to combine into a single hyperpipe.  Each call to
  964.        pfHyperpipe() defines a separate hyperpipe instance. For
  965.        example, two calls to pfHyperpipe() with an argument of 2
  966.        would define two hyperpipes of 2 _p_f_P_i_p_es each to Performer.
  967.        Like pfMultipipe(), this routine can only be invoked prior
  968.        to pfConfig().  Additionally, the _p_f_P_i_p_es of the hyperpipes
  969.        will be the lowest numbered _p_f_P_i_p_es, with any non-hyperpipe
  970.        _p_f_P_i_p_es appearing at the end.
  971.  
  972.        The first (lowest numbered) _p_f_P_i_p_e of the hyperpipe is the
  973.        master.  In the above example, that would be _p_f_P_i_p_es 0 and
  974.        2.  All control of the hyperpipe should be made through the
  975.        master _p_f_P_i_p_e. For example, to construct a _p_f_P_i_p_e_W_i_n_d_o_w for
  976.        a hyperpipe, the application can simply create it on the
  977.        master _p_f_P_i_p_e. The cloned _p_f_P_i_p_e_W_i_n_d_o_ws for each _p_f_P_i_p_e in
  978.        the hyperpipe will be created automatically. While allowed,
  979.        constructing a _p_f_P_i_p_e_W_i_n_d_o_w on a non-master pipe of the
  980.        hyperpipe will lead to undefined results.
  981.  
  982.        Hyperpipes differ from other multipipe configurations in one
  983.  
  984.  
  985.  
  986.  
  987.  
  988.  
  989.  
  990.  
  991.  
  992.  
  993.  
  994.                                   - 16 -
  995.  
  996.  
  997.  
  998.        other very important way. The set of _p_f_C_h_a_n_n_e_l_s displayed on
  999.        the hyperpipe is shared amongst all of the _p_f_P_i_p_e_s in the
  1000.        hyperpipe.  That is, it is only necessary to create and set
  1001.        _p_f_C_h_a_n_n_e_l objects on the master _p_f_P_i_p_e of the hyperpipe.
  1002.        Since the hyperpipe is a time multiplexed view of these
  1003.        channels, Performer will propagate changes in the _p_f_C_h_a_n_n_e_l
  1004.        to each of the _p_f_P_i_p_e_s in turn.
  1005.  
  1006.        The following code snippet identifies the steps needed to
  1007.        setup a multi-hyperpipe config. It assumes that each of the
  1008.        hyperpipes are symetric (i.e., have the same number of
  1009.        pipes), although this is not required by Performer.
  1010.  
  1011.  
  1012.        ////****
  1013.         **** LLLLooooccccaaaallll ddddeeeeccccllllaaaarrrraaaattttiiiioooonnnnssss
  1014.         ****////
  1015.        iiiinnnntttt iiii;;;;
  1016.        ppppffffCCCChhhhaaaannnnnnnneeeellll**** mmmmaaaasssstttteeeerrrrCCCChhhhaaaannnn;;;;
  1017.        ppppffffPPPPiiiippppeeeeWWWWiiiinnnnddddoooowwww**** mmmmaaaasssstttteeeerrrrPPPPWWWWiiiinnnn;;;;
  1018.  
  1019.        ////****
  1020.         **** TTTThhhheeee ffffoooolllllllloooowwwwiiiinnnngggg aaaassssssssuuuummmmeeeessss tttthhhhaaaatttt hhhhyyyyppppeeeerrrrppppiiiippppeeeeCCCCoooouuuunnnntttt iiiissss tttthhhheeee nnnnuuuummmmbbbbeeeerrrr ooooffff
  1021.         **** hhhhyyyyppppeeeerrrrppppiiiippppeeeessss ttttoooo ccccoooonnnnffffiiiigggguuuurrrreeee aaaannnndddd hhhhyyyyppppeeeerrrrppppiiiippppeeeePPPPiiiippppeeeeCCCCoooouuuunnnntttt iiiissss tttthhhheeee nnnnuuuummmmbbbbeeeerrrr
  1022.         **** ppppiiiippppeeeessss ppppeeeerrrr hhhhyyyyppppeeeerrrrppppiiiippppeeee....
  1023.         ****////
  1024.        iiiinnnntttt ppppiiiippppeeeeCCCCoooouuuunnnntttt ==== hhhhyyyyppppeeeerrrrppppiiiippppeeeeCCCCoooouuuunnnntttt****hhhhyyyyppppeeeerrrrppppiiiippppeeeePPPPiiiippppeeeeCCCCoooouuuunnnntttt;;;;
  1025.  
  1026.        ffffoooorrrr ((((iiii ==== 0000;;;; iiii <<<< hhhhyyyyppppeeeerrrrppppiiiippppeeeeCCCCoooouuuunnnntttt;;;; iiii++++++++))))
  1027.            ppppffffHHHHyyyyppppeeeerrrrppppiiiippppeeee((((hhhhyyyyppppeeeerrrrppppiiiippppeeeePPPPiiiippppeeeeCCCCoooouuuunnnntttt))));;;;
  1028.  
  1029.        ////****
  1030.         **** CCCCoooonnnnffffiiiigggguuuurrrreeee PPPPeeeerrrrffffoooorrrrmmmmeeeerrrr
  1031.         ****////
  1032.        ppppffffCCCCoooonnnnffffiiiigggg(((())));;;;
  1033.  
  1034.        ////****
  1035.         **** CCCCoooonnnnffffiiiigggguuuurrrreeee tttthhhheeee ssssccccrrrreeeeeeeennnnssss ffffoooorrrr tttthhhheeee ppppffffPPPPiiiippppeeeessss
  1036.         ****
  1037.         **** AAAAssssssssuuuummmmeeeessss aaaallllllll ssssaaaammmmeeee ddddiiiissssppppllllaaaayyyy aaaannnndddd ssssccccrrrreeeeeeeennnn aaaassssssssiiiiggggnnnnmmmmeeeennnnttttssss tttthhhhaaaatttt mmmmaaaapppp
  1038.         **** ttttoooo ppppffffPPPPiiiippppeeee nnnnuuuummmmbbbbeeeerrrr
  1039.         ****////
  1040.        ffffoooorrrr ((((iiii ==== 0000;;;; iiii <<<< ppppiiiippppeeeeCCCCoooouuuunnnntttt;;;; iiii++++++++))))
  1041.            ppppffffPPPPiiiippppeeeeSSSSccccrrrreeeeeeeennnn((((ppppffffGGGGeeeettttPPPPiiiippppeeee((((iiii)))),,,, iiii))));;;;  //////// aaaassssssssuuuummmmeeeessss aaaallllllll oooonnnn ssssaaaammmmeeee ddddiiiissssppppllllaaaayyyy
  1042.  
  1043.        ////****
  1044.         **** CCCCoooonnnnffffiiiigggguuuurrrreeee aaaa tttthhhhrrrreeeeeeee,,,, ttttwwwwoooo----ppppiiiippppeeee hhhhyyyyppppeeeerrrrppppiiiippppeeee ffffoooorrrr mmmmuuuullllttttiiii----cccchhhhaaaannnnnnnneeeellll ddddiiiissssppppllllaaaayyyy....
  1045.         ****////
  1046.        ffffoooorrrr ((((iiii ==== 0000;;;; iiii <<<< ppppiiiippppeeeeCCCCoooouuuunnnntttt;;;; iiii ++++==== hhhhyyyyppppeeeerrrrppppiiiippppeeeePPPPiiiippppeeeeCCCCoooouuuunnnntttt)))) {{{{
  1047.            ppppffffPPPPiiiippppeeee**** pppp;;;;
  1048.            ppppffffPPPPiiiippppeeeeWWWWiiiinnnnddddoooowwww**** ppppwwww;;;;
  1049.  
  1050.  
  1051.  
  1052.  
  1053.  
  1054.  
  1055.  
  1056.  
  1057.  
  1058.  
  1059.  
  1060.                                   - 17 -
  1061.  
  1062.  
  1063.  
  1064.            ppppffffCCCChhhhaaaannnnnnnneeeellll**** cccchhhhaaaannnn;;;;
  1065.            iiiinnnntttt sssshhhhaaaarrrreeee;;;;
  1066.            PPPPFFFFVVVVEEEECCCC3333 xxxxyyyyzzzz,,,, hhhhpppprrrr;;;;
  1067.  
  1068.            pppp ==== ppppffffGGGGeeeettttPPPPiiiippppeeee((((iiii))));;;;
  1069.            ppppwwww ==== ppppffffNNNNeeeewwwwPPPPWWWWiiiinnnn((((pppp))));;;;
  1070.            ppppffffPPPPWWWWiiiinnnnNNNNaaaammmmeeee((((ppppwwww,,,, """"HHHHyyyyppppeeeerrrrppppiiiippppeeee WWWWiiiinnnnddddoooowwww""""))));;;;
  1071.            ppppffffPPPPWWWWiiiinnnnCCCCoooonnnnffffiiiiggggFFFFuuuunnnncccc((((ppppwwww,,,, OOOOppppeeeennnnPPPPiiiippppeeeeWWWWiiiinnnn))));;;;
  1072.            ppppffffPPPPWWWWiiiinnnnTTTTyyyyppppeeee((((ppppwwww,,,, PPPPFFFFPPPPWWWWIIIINNNN____TTTTYYYYPPPPEEEE____XXXX))));;;;
  1073.            ppppffffPPPPWWWWiiiinnnnFFFFuuuullllllllSSSSccccrrrreeeeeeeennnn((((ppppwwww))));;;;
  1074.            ppppffffPPPPWWWWiiiinnnnMMMMooooddddeeee((((ppppwwww,,,, PPPPFFFFWWWWIIIINNNN____NNNNOOOOBBBBOOOORRRRDDDDEEEERRRR,,,, 1111))));;;;
  1075.            ppppffffCCCCoooonnnnffffiiiiggggPPPPWWWWiiiinnnn((((ppppwwww))));;;;
  1076.            iiiiffff ((((iiii ======== 0000)))) mmmmaaaasssstttteeeerrrrPPPPWWWWiiiinnnn ==== ppppwwww;;;;
  1077.  
  1078.            cccchhhhaaaannnn ==== ppppffffNNNNeeeewwwwCCCChhhhaaaannnn((((pppp))));;;;
  1079.            sssshhhhaaaarrrreeee ==== ppppffffGGGGeeeettttCCCChhhhaaaannnnSSSShhhhaaaarrrreeee((((cccchhhhaaaannnn))));;;;
  1080.            sssshhhhaaaarrrreeee ||||==== PPPPFFFFCCCCHHHHAAAANNNN____VVVVIIIIEEEEWWWWPPPPOOOORRRRTTTT |||| PPPPFFFFCCCCHHHHAAAANNNN____SSSSWWWWAAAAPPPPBBBBUUUUFFFFFFFFEEEERRRRSSSS ||||
  1081.                     PPPPFFFFCCCCHHHHAAAANNNN____SSSSWWWWAAAAPPPPBBBBUUUUFFFFFFFFEEEERRRRSSSS____HHHHWWWW;;;;
  1082.            ppppffffCCCChhhhaaaannnnSSSShhhhaaaarrrreeee((((cccchhhhaaaannnn,,,, sssshhhhaaaarrrreeee))));;;;
  1083.            ppppffffMMMMaaaakkkkeeeeSSSSiiiimmmmpppplllleeeeCCCChhhhaaaannnn((((cccchhhhaaaannnn,,,, 44445555))));;;;
  1084.            ppppffffCCCChhhhaaaannnnAAAAuuuuttttooooAAAAssssppppeeeecccctttt((((cccchhhhaaaannnn,,,, PPPPFFFFFFFFRRRRUUUUSSSSTTTT____CCCCAAAALLLLCCCC____VVVVEEEERRRRTTTT))));;;;
  1085.            ppppffffAAAAddddddddCCCChhhhaaaannnn((((ppppwwww,,,, cccchhhhaaaannnn))));;;;
  1086.  
  1087.            ppppffffSSSSeeeettttVVVVeeeecccc3333((((xxxxyyyyzzzz,,,, 0000,,,, 0000,,,, 0000))));;;;
  1088.            ppppffffSSSSeeeettttVVVVeeeecccc3333((((hhhhpppprrrr,,,, ((((((((hhhhyyyyppppeeeerrrrppppiiiippppeeeeCCCCoooouuuunnnntttt----1111)))) **** ....5555ffff
  1089.                         ---- iiii////hhhhyyyyppppeeeerrrrppppiiiippppeeeePPPPiiiippppeeeeCCCCoooouuuunnnntttt )))) **** 44445555....ffff,,,, 0000,,,, 0000))));;;;
  1090.            ppppffffCCCChhhhaaaannnnVVVViiiieeeewwwwOOOOffffffffsssseeeettttssss((((cccchhhhaaaannnn,,,, xxxxyyyyzzzz,,,, hhhhpppprrrr))));;;;
  1091.            iiiiffff ((((iiii ======== 0000))))
  1092.                mmmmaaaasssstttteeeerrrrCCCChhhhaaaannnn ==== cccchhhhaaaannnn;;;;
  1093.            eeeellllsssseeee
  1094.                ppppffffAAAAttttttttaaaacccchhhhCCCChhhhaaaannnn((((mmmmaaaasssstttteeeerrrrCCCChhhhaaaannnn,,,, cccchhhhaaaannnn))));;;;
  1095.        }}}}
  1096.  
  1097.        The remainder of the code should follow a typical multipipe
  1098.        application.
  1099.  
  1100.        There are certain restrictions on usage of _p_f_P_i_p_es,
  1101.        _p_f_P_i_p_e_W_i_n_d_o_ws and _p_f_P_i_p_e_V_i_d_e_o_C_h_a_n_n_e_ls when running in
  1102.        hyperpipe mode. All actions (with the exception of graphics
  1103.        pipe specific controls, e.g., pfPWinFBConfigAttrs() and
  1104.        pfPWinFBConfigId) should occur on those objects associated
  1105.        with the master _p_f_P_i_p_e.  In those instances where pipe
  1106.        specific attributes need modification, the appropriate
  1107.        pfPipeWindow or pfPipeVideoChannel can be obtained using the
  1108.        indexed pfGetPipePWin and pfGetPWinPVChan functions.  The
  1109.        index should equal the index of the associated master object
  1110.        on the master pipe.
  1111.  
  1112.        There is a limitation in that changes to _p_f_P_i_p_e_W_i_n_d_o_ws
  1113.        affected by the draw process will not be propagated to other
  1114.        _p_f_P_i_p_e_W_i_n_d_o_ws in the hyperpipe. Also, statistics drawn by
  1115.  
  1116.  
  1117.  
  1118.  
  1119.  
  1120.  
  1121.  
  1122.  
  1123.  
  1124.  
  1125.  
  1126.                                   - 18 -
  1127.  
  1128.  
  1129.  
  1130.        the _p_f_F_r_a_m_e_S_t_a_t_s will reflect only the times for a
  1131.        particular draw process and not the entire hyperpipe. These
  1132.        problems may be removed in a later release.
  1133.  
  1134.  
  1135.        6.11  _C_h_a_n_g_e_s__i_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._2_._3
  1136.  
  1137.        6.11.1  _P_r_o_b_l_e_m_s__f_i_x_e_d__i_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._2_._3
  1138.  
  1139.           +o Performer 2.2 always used the channel frustum for
  1140.             culling when PFCULL_GSET was set, even if a custom cull
  1141.             frustum polytope was defined.  This has been fixed.
  1142.             (SCR 635693)
  1143.  
  1144.           +o Attempting to delete a cliptexture could cause a core
  1145.             dump.  Cliptexture deletion is not supported, so a
  1146.             DEBUG-level warning is now emitted.  (SCR 594276)
  1147.  
  1148.           +o Fully transparent pfLPointStates could cause
  1149.             segmentation violations in Performer 2.2.  This has
  1150.             been fixed.  (SCR 614274)
  1151.  
  1152.           +o The FLT loader printed assertion failures such as the
  1153.             following:
  1154.  
  1155.                +o pfdConverterMode_flt: user data slot cannot be set
  1156.                  to 1
  1157.  
  1158.                +o pfdConverterMode_flt: private user data slot
  1159.                  cannot be set to 2
  1160.  
  1161.             The cause of these problems has been fixed.  (SCR
  1162.             624177)
  1163.  
  1164.           +o pfdFindConverterDSO was unable to locate the 3ds file
  1165.             loader. This was the result of conflicting IL and IFL
  1166.             versions and has been fixed.  (SCR 625838)
  1167.  
  1168.           +o The warning "pfTexture::compare(): pfClipTexture is not
  1169.             a pfTexture" was emitted when comparing a pfGeoState
  1170.             with cliptexture to one with a regular texture.  This
  1171.             has been fixed.  (SCR 626001)
  1172.  
  1173.           +o Picking with orthographic viewing frusta returned
  1174.             incorrect hit points.  This has been fixed.  (SCR
  1175.             601650)
  1176.  
  1177.           +o Color fields in pfGeoSets were not being handled
  1178.             correctly during the print traversal.  This has been
  1179.             fixed.  (SCR 621124)
  1180.  
  1181.  
  1182.  
  1183.  
  1184.  
  1185.  
  1186.  
  1187.  
  1188.  
  1189.  
  1190.  
  1191.  
  1192.                                   - 19 -
  1193.  
  1194.  
  1195.  
  1196.           +o pfuTravCalcBBox in trav.c did not calculate the
  1197.             bounding box for pfBillboard nodes.  It now does.  (SCR
  1198.             632225)
  1199.  
  1200.  
  1201.  
  1202.        6.12  _C_h_a_n_g_e_s__i_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._2_._2
  1203.  
  1204.        6.12.1  _P_r_o_b_l_e_m_s__f_i_x_e_d__i_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._2_._2
  1205.  
  1206.           +o _p_f_B_i_l_l_b_o_a_r_d_s were always using Z axis (Bug #591154)
  1207.  
  1208.           +o _p_f_P_i_p_e_W_i_n_d_o_w _r_e_s_i_z_e _w_i_t_h _f_o_r_k_e_d _c_u_l_l caused per-frame
  1209.             slow X communication. (Bug #611816)
  1210.  
  1211.           +o _p_f_T_e_x_t_u_r_e _w_i_t_h _T_e_x_L_O_D _s_e_t_t_i_n_g_s would leak memory. (Bug
  1212.             #600949)
  1213.  
  1214.           +o _p_f_U_n_r_e_f_D_e_l_e_t_e() would delete an object when its ref
  1215.             count was decremented to 65536.  This has been fixed,
  1216.             and the types of pfGetRef() and pfUnrefGetRef() have
  1217.             been changed from ushort to int. (Bug #603177)
  1218.  
  1219.           +o The _l_o_o_k_a_h_e_a_d directive was ignored in no-imagecache
  1220.             ._c_t _c_l_i_p _t_e_x_t_u_r_e _c_o_n_f_i_g_u_r_a_t_i_o_n _f_i_l_e_s.  _N_O_T_E: since this
  1221.             is fixed, applications using .ct files containing a
  1222.             lookahead command may use much more memory, and may
  1223.             have to be re-tuned (or the lookahead command removed).
  1224.             (Bug #576096)
  1225.  
  1226.           +o The CSB loader has been updated to enable loading of
  1227.             files created by OpenGL Optimizer 1.2
  1228.  
  1229.           +o The FLT loader has been updated to version 15.4g (Bug
  1230.             #615990).  Several bugs have been fixed, including:
  1231.  
  1232.                +o A bug in revision R15.4fi where
  1233.                  pfuTexGenClipCenterNode was inserted as parent of
  1234.                  root node.  In such cases the clip texture was not
  1235.                  centered.
  1236.  
  1237.                +o A bug in revision R15.4fi where the loader's user
  1238.                  data slot was not initialized.  This caused core
  1239.                  dumps when certain run-time features were enabled
  1240.                  such as clip planes, behaviors, and adaptive light
  1241.                  points.
  1242.  
  1243.                +o _P_r_o_j_e_c_t_e_d _t_e_x_t_u_r_e_s behaved improperly when using
  1244.                  multiple channels or when lighting was off. (Bugs
  1245.                  #581332, #581334)
  1246.  
  1247.  
  1248.  
  1249.  
  1250.  
  1251.  
  1252.  
  1253.  
  1254.  
  1255.  
  1256.  
  1257.  
  1258.                                   - 20 -
  1259.  
  1260.  
  1261.  
  1262.                +o _I_n_f _f_r_a_m_e _r_a_t_e _r_e_p_o_r_t_e_d _f_o_r _I_n_t_e_r_l_a_c_e_d _v_i_d_e_o
  1263.                  _f_o_r_m_a_t_s.  Now, the current swap rate will be
  1264.                  reported which for interlaced video formats might
  1265.                  be faster than the requested frame rate (ie.
  1266.                  60/30Hz).  (Bug #603567).
  1267.  
  1268.                +o _v_i_s_f_l_y _d_e_m_o was unable to start due to an
  1269.                  unresolvable symbol in the compat libraries,
  1270.                  pfuCalcNormalizedChanXY (Bug #600942)
  1271.  
  1272.                +o _B_a_d _L_i_g_h_t_i_n_g - the 2.0.6/2.1.4 compat libraries
  1273.                  had bad lighting characteristics; all lit models
  1274.                  were shaded grey  (Bug #598903)
  1275.  
  1276.                +o _p_f_d_F_i_n_d_C_o_n_v_e_r_t_e_r_D_S_O() in 2.0.6/2.1.4 was failing
  1277.                  due to a lookup problem in pfdLoadFile.  (Bug
  1278.                  #605958)
  1279.  
  1280.                +o _6_4_b_i_t _o_p_e_r_a_t_i_o_n _w_i_t_h _I_R_I_X _6._5 could fail with IRIS
  1281.                  Performer 2.0 and 2.1 libraries.  This is fixed in
  1282.                  the IRIS Performer libraries that were shipped
  1283.                  with IRIX 6.5 and also in the 2.0.7/2.1.5
  1284.                  libraries.
  1285.  
  1286.  
  1287.        6.13  _C_h_a_n_g_e_s__i_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._2_._1
  1288.  
  1289.        6.13.1  _P_r_o_b_l_e_m_s__f_i_x_e_d__i_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._2_._1
  1290.  
  1291.           +o _a_s_d_f_l_y _z_b_u_f_f_e_r _p_r_o_b_l_e_m_s _o_n _i_R due to a lose layer
  1292.             offset call in asdfly/terrain.c. (Bug #575993)
  1293.  
  1294.           +o _M_u_l_t_i_p_i_p_e _C_a_l_l_i_g_r_a_p_h_i_c_s supports 10 pipes instead of
  1295.             just 3.  (Bug #559773)
  1296.  
  1297.           +o _M_u_l_t_i_p_i_p_e _p_f_G_e_t_S_c_r_e_e_n() _r_e_t_u_r_n_i_n_g (-_1)_i_n _d_r_a_w _s_t_a_g_e
  1298.             _c_a_l_l_b_a_c_k _i_n_i_t..
  1299.  
  1300.           +o _O_p_e_n_W_o_r_l_d_s _V_R_M_L _2._0 (._w_r_l) _l_o_a_d_e_r failed for N32 and
  1301.             N64 due to default library search path
  1302.             (/usr/lib[32,64]. (Bug #575792)
  1303.  
  1304.           +o _O_p_e_n_F_l_i_g_h_t (._f_l_t) _l_o_a_d_e_r _w_i_t_h _a_u_t_o_m_a_t_i_c _c_l_i_p_t_e_x_t_u_r_e
  1305.             _c_e_n_t_e_r_i_n_g could dump core if pfuInit() was not called
  1306.             by the application before pfConfig().  (Bug #575589)
  1307.  
  1308.           +o _O_p_e_n_F_l_i_g_h_t (._f_l_t) _l_o_a_d_e_r _u_s_i_n_g _n_e_w _1_5._4 _f_e_a_t_u_r_e_s could
  1309.             dump core due to lack of initialization of user data
  1310.             slot used for behaviors and clip planes.  (Bug #575586)
  1311.  
  1312.  
  1313.  
  1314.  
  1315.  
  1316.  
  1317.  
  1318.  
  1319.  
  1320.  
  1321.  
  1322.  
  1323.  
  1324.                                   - 21 -
  1325.  
  1326.  
  1327.  
  1328.           +o _X_s_g_i_v_c _V_i_d_e_o _C_h_a_n_n_e_l _0 had to exist or Performer would
  1329.             hang on startup.  This also caused hangs on OCTANE OCO
  1330.             (multi-channel operation).  (Bug #577815)
  1331.  
  1332.           +o _N_6_4 _V_i_d_e_o _c_h_a_n_n_e_l _o_p_e_r_a_t_i_o_n_s would dump core (Bug
  1333.             #575616).  To see this fix on IRIX 6.2 or IRIX 6.4,
  1334.             additional X and GL patches are required.
  1335.  
  1336.           +o _I_n _O_c_t_a_n_e _O_C_O _m_o_d_e  _o_r _n_o _v_i_d_e_o _c_h_a_n_n_e_l  would result
  1337.             in no pfPipeWindow being opened. (Bug #577065).
  1338.  
  1339.           +o _D_V_R _s_h_o_w_i_n_g _n_o_i_s_e _o_n _b_o_t_t_o_m _l_i_n_e_s _o_f _v_i_d_e_o. (Bug
  1340.             #577976).
  1341.  
  1342.           +o _p_f_i_S_p_h_e_r_i_c _m_o_t_i_o_n _m_o_d_e_l _t_r_a_n_s_i_t_i_o_n (rail) tracking was
  1343.             too fast for really slow speeds (in the range of
  1344.             0.000001).  (Bug #583127).
  1345.  
  1346.  
  1347.        6.13.2  _P_r_o_b_l_e_m_s _f_i_x_e_d _i_n _2._0._6 _a_n_d _2._1._4 (_s_h_i_p_p_e_d _w_i_t_h
  1348.        _2._2._1)
  1349.  
  1350.           +o _p_f_u_C_o_n_f_i_g_M_C_O now properly initializes multiple channels
  1351.             on multiple pipes. (Bug #564062)
  1352.  
  1353.           +o _p_f_W_i_n_d_o_w::_g_e_t_F_B_C_o_n_f_i_g_A_t_t_r_s() was core dumping on
  1354.             pbuffers.  It will now return NULL for a pbuffer since
  1355.             the attribute arrays is for XVisuals and pbuffers
  1356.             require GLXFBConfigSGIXs which should be specified with
  1357.             pfWindow::setFBConfig(). (Bug #575989)
  1358.  
  1359.           +o _p_f_u_S_a_v_e_I_m_a_g_e _i_n _N_6_4 didn't work due to bad pointer
  1360.             types in libpfutil/snapwin.c. (Bug #575243)
  1361.  
  1362.           +o _N_6_4 _p_l_a_c_e_m_e_n_t _o_f _p_f_D_a_t_a_P_o_o_l_s could cause brk to run out
  1363.             of space for heap area. (Bug #575065)
  1364.  
  1365.  
  1366.        6.14  _C_h_a_n_g_e_s__i_n__I_R_I_S__P_e_r_f_o_r_m_e_r__2_._2
  1367.  
  1368.        6.14.1  _I_R_I_S__P_e_r_f_o_r_m_e_r__2_._0_._4__P_r_o_b_l_e_m_s__f_i_x_e_d__i_n__2_._0_._5__a_n_d__2_._2
  1369.  
  1370.  
  1371.           +o _p_f_I_n_i_t_C_l_o_c_k in 250MHz IMPACT use not to be consistent.
  1372.  
  1373.           +o _P_i_c_k_i_n_g models with LOD unded DCS used to fail with
  1374.             large DCS translations (bug#455490)
  1375.  
  1376.           +o _p_f_T_e_x_t_u_r_e sometime failed to restore to the global
  1377.             texture.
  1378.  
  1379.  
  1380.  
  1381.  
  1382.  
  1383.  
  1384.  
  1385.  
  1386.  
  1387.  
  1388.  
  1389.  
  1390.                                   - 22 -
  1391.  
  1392.  
  1393.  
  1394.           +o _p_f_B_o_x contains function has been fixed
  1395.  
  1396.           +o _D_a_t_a_P_o_o_l were not aligned on 64 bits, generating core
  1397.             dump if the application store double float in the
  1398.             datapool.
  1399.  
  1400.           +o Some _q_u_e_r_y feature request were missing, 2.0.5 is now
  1401.             at the same level as 2.2.
  1402.  
  1403.           +o Assigning a Drawable without a visual used to cause the
  1404.             window not to open. (bug# 450891)
  1405.  
  1406.           +o Full screen had a window border when compiling for N64.
  1407.             (bug #542372)
  1408.  
  1409.           +o _p_b_u_f_f_e_r were not fully supported.
  1410.  
  1411.  
  1412.        6.14.2  _I_R_I_S__P_e_r_f_o_r_m_e_r__2_._1_._2__P_r_o_b_l_e_m_s__f_i_x_e_d__i_n__2_._1_._3__a_n_d__2_._2
  1413.  
  1414.  
  1415.           +o When the first video channel on a graphic pipeline was
  1416.             not active, _p_f_P_i_p_e_V_i_d_e_o_C_h_a_n_n_e_l was failing under forked
  1417.             DRAW multi-process.
  1418.  
  1419.           +o _A_S_D _T_e_r_r_a_i_n was not supporting dynamic paging. This
  1420.             fixed so ASD tiles can be dynamically paged in the
  1421.             DBASE prmcess.
  1422.  
  1423.           +o _A_S_D _T_e_r_r_a_i_n was not working on multipipe. This is fixed
  1424.             and ASD works fine with multiple pipes/channels. _a_s_d_f_l_y
  1425.             is fixed as well.
  1426.  
  1427.           +o _V_e_r_t_e_x _a_r_r_a_y_s used in a GL display list used to produce
  1428.             invalid normals.  This has been fixed in OpenGL with
  1429.             patch 1808 or later.
  1430.  
  1431.           +o _p_f_T_e_x_t_u_r_e sometime failed to restore to the global
  1432.             texture.
  1433.  
  1434.           +o _p_f_B_o_x contains function has been fixed
  1435.  
  1436.           +o _D_a_t_a_P_o_o_l were not aligned on 64 bits, generating core
  1437.             dump if the application store double float in the
  1438.             datapool.
  1439.  
  1440.           +o Full screen had a window border when compiling for N64.
  1441.             (bug #542372)
  1442.  
  1443.           +o Some _q_u_e_r_y feature request were missing, 2.1.3 is now
  1444.             at the same level as 2.2.
  1445.  
  1446.  
  1447.  
  1448.  
  1449.  
  1450.  
  1451.  
  1452.  
  1453.  
  1454.  
  1455.  
  1456.                                   - 23 -
  1457.  
  1458.  
  1459.  
  1460.           +o _M_o_t_i_f decoration hints used not to work in 64 bits N64.
  1461.  
  1462.  
  1463.        6.14.3  _O_t_h_e_r__P_r_o_b_l_e_m_s__f_i_x_e_d__i_n__2_._2
  1464.  
  1465.           +o _I_n_v_e_n_t_o_r loader used not to work N32/N64. (bug# 434322)
  1466.  
  1467.           +o _G_a_n_g_S_w_a_p was not working at all for OpenGL. This is
  1468.             fixed in performer and in OpenGL after patch 1808.
  1469.  
  1470.           +o _p_e_r_f_l_y did not accept input from other screens than the
  1471.             master screen. (bug# 459186)
  1472.  
  1473.           +o _E_a_r_t_h_S_k_y used not to propagate the right fog values in
  1474.             sync to all screens in multipipe mode (bug# 437747)
  1475.  
  1476.           +o _s_h_a_d_o_w _t_e_x_t_u_r_e_s used not to be implemented for
  1477.             InfiniteReality/OpenGL.
  1478.  
  1479.           +o _p_f_c_o_n_v did core dump or go in infinite loop when
  1480.             converting some inventor files. (bug# 435232)
  1481.  
  1482.           +o _g_l_o_b_a_l _s_t_a_t_e used not to work properly and be in
  1483.             conflict with channel state (see option -q0 in perfly).
  1484.             (bug# 423829)
  1485.  
  1486.           +o _B_i_n_s used to have many problems. Bin number had to be
  1487.             in successive numbers (bug# 416557), bin Order had no
  1488.             effect at all, there was no way to draw the objects
  1489.             that are not falling into a bin (can be done in 2.2
  1490.             using pfDrawBin(-1)), there was no way to know which
  1491.             bins are in used (pfGetFreeBin() gets that information
  1492.             in 2.2). Note that 2.2 has a predefined #3 bin: the
  1493.             Light Point bin, and that this bin has a very special
  1494.             behavior and cannot be used for general purpose.
  1495.  
  1496.           +o _p_f_A_S_D used to only handle terrain with less than 65000
  1497.             vertices.
  1498.  
  1499.           +o _p_f_d_B_u_i_l_d_A_S_D used to have memory corruptions.
  1500.  
  1501.           +o _D_V_R used to produce garbage when used on a screen
  1502.             larger than 1280 pixels. Performer now prevent scaling
  1503.             in X direction as the hardware does not support it. It
  1504.             is not going to be fixed in OpenGL, it is a HW
  1505.             bandwidth limitation.
  1506.  
  1507.           +o _g_l_N_o_r_m_a_l_i_z_e was turned on by default, resulting in a
  1508.             minimal loss of performances. Now it is automatically
  1509.             turned on only when the current transformation matrix
  1510.             includes scaling, and turned off otherwise.
  1511.  
  1512.  
  1513.  
  1514.  
  1515.  
  1516.  
  1517.  
  1518.  
  1519.  
  1520.  
  1521.  
  1522.                                   - 24 -
  1523.  
  1524.  
  1525.  
  1526.           +o Some _p_f_M_a_t_h routines were slower than system libmath
  1527.             routines that are now very optimized. The corresponding
  1528.             pfMath routines are replaced by a #define that calls
  1529.             system math routines directly.
  1530.  
  1531.           +o _C_l_i_p_t_e_x_t_u_r_e have been upgraded to production standards
  1532.             for IRIS Performer 2.2. The core cliptexture
  1533.             functionality has been respecified to tighter
  1534.             tolerances, critical functionality such as load control
  1535.             and virtual cliptextures has been added, and additional
  1536.             API in libpfutil and libpfdu has been put in to make
  1537.             cliptextures easier to use in production applications.
  1538.  
  1539.           +o _p_e_r_f_l_y -_t now allows specification of visual ID for
  1540.             each pipe as a comma-separated list.
  1541.  
  1542.           +o _p_f_F_o_n_t._h in previous versions was missing some internal
  1543.             fields in the class declaration that would cause
  1544.             problems for C++ user code creating pfFont structures
  1545.             and the allocates structures would not be the proper
  1546.             size.
  1547.  
  1548.  
  1549.  
  1550.        6.14.4  _D_i_f_f_e_r_e_n_c_e_s__B_e_t_w_e_e_n__2_._2__a_n_d__2_._0_/_2_._1
  1551.        IRIS Performer 2.1 is an enhanced version of the IRIS
  1552.        Performer 2.0 release designed in conjunction with the Onyx
  1553.        InfiniteReality graphics hardware. It is, in essence,
  1554.        "Performer 2.0 with InfiniteReality extensions." Unlike IRIS
  1555.        Performer 2.1 that was only for InfiniteReality, the new
  1556.        IRIS Performer 2.2 is an enhanced version of IRIS Performer
  1557.        2.0/2.1 that runs on all SGI plateformes, enabling hardware
  1558.        specific features (DVR, ClipMapping) only when supported
  1559.        directly by the Graphic Subsystem.  IRIS Performer 2.2 has
  1560.        numerous improvements and new features over 2.0/2.1 such as
  1561.        pfFlux, pfb/pfi file formats, compute process for ASD,
  1562.        Calligraphic light support....  IRIS Performer 2.0 API is
  1563.        almost unchanged into 2.2, but it is not the case for 2.1 as
  1564.        the ClipMapping and ASD have had a lot of API changes.
  1565.  
  1566.  
  1567.        6.14.4.1  _C_l_i_p_T_e_x_t_u_r_e
  1568.  
  1569.        InfiniteReality supports very large textures through a
  1570.        virtual mipmapped texture scheme we call cliptexturing. Here
  1571.        is a preview of the basic concepts.
  1572.  
  1573.        Clip Textures provide a way use texture maps too large to
  1574.        hold in graphics texture memory. Until now, to use a large
  1575.        texture, you had to break it into tiles, bringing in the
  1576.        next texture as you approached a tile boundary.  This
  1577.  
  1578.  
  1579.  
  1580.  
  1581.  
  1582.  
  1583.  
  1584.  
  1585.  
  1586.  
  1587.  
  1588.                                   - 25 -
  1589.  
  1590.  
  1591.  
  1592.        approach has numerous problems, including what to do about
  1593.        polygons that span texture tile boundaries, properly
  1594.        handling the changes in texture coordinates, doing
  1595.        MIPMapping without visual artifacts, etc.  Performer Clip
  1596.        Textures solve these problems. They allow you to seamlessly
  1597.        use a very large texture, letting performer handle the
  1598.        loading issues.  Since it is one continuous texture, there
  1599.        are no problems with texture seams or changes in texture
  1600.        coordinates.
  1601.  
  1602.        A clip texture can be thought of as a very large mipmapped
  1603.        texture. The dimensions of level 0, the highest resolution
  1604.        level of the texture, is the clip texture's *virtual size*.
  1605.        For any given scene, only a subset of the entire clip
  1606.        texture is visible to the observer. pfClipTextures augment
  1607.        pfTextures by adding the notion of a center, a location in
  1608.        texel space that is close to the observer. As the center
  1609.        moves, the cliptexture must repeatedly applied, to update
  1610.        the texels in texture memory, so that contains the texels
  1611.        surrounding the current center.
  1612.  
  1613.        With the center properly updated, only a subset of the
  1614.        entire cliptexture need be loaded into texture memory at any
  1615.        given time. The visible region of this texture is called the
  1616.        *clip region*. The contents of this region are updated as
  1617.        the cliptexture center changes, always keeping the
  1618.        surrounding texel data available to the texturing hardware.
  1619.        The clip region can be visualized as a fixed width square
  1620.        column cutting through the mipmap levels. At the coarsest
  1621.        levels, where the MIPmap level becomes smaller than the clip
  1622.        region size, the cliptexture is a normal MIPmap pyramid. As
  1623.        the center moves on level 0, the column shears so that it
  1624.        surrounds the center, each level moving half as fast as the
  1625.        finer level above it.
  1626.  
  1627.        The texture itself is stored on disk and system memory as
  1628.        *tiles*. One or more tiles are stored as *texture tile
  1629.        files* on disk, and are brought into system memory as
  1630.        needed. A cache of these tiles, called the *memory region*
  1631.        is kept in system memory to reduce disk latency. A subset of
  1632.        the memory region texels, the *texture region* are
  1633.        downloaded to the graphics hardware texture memory.
  1634.  
  1635.        Each level of the clip texture larger than the clip size is
  1636.        contained in an level updated with the proper texel data,
  1637.        based on the center position at that level. The image cache
  1638.        must download texel data as tiles from the appropriate
  1639.        texture data files, keeping the mem region updated, and use
  1640.        texture subloads to update texel data from the texture
  1641.        region into proper area of hardware texture memory.  The
  1642.        clip texture itself is composed of image caches and image
  1643.  
  1644.  
  1645.  
  1646.  
  1647.  
  1648.  
  1649.  
  1650.  
  1651.  
  1652.  
  1653.  
  1654.                                   - 26 -
  1655.  
  1656.  
  1657.  
  1658.        tiles. The image tiles describe the levels of the mipmap
  1659.        pyramid that are equal to or smaller than the clip region.
  1660.        It updates the clip texture center, and commands the image
  1661.        caches to reapply the texture memory as the center changes.
  1662.  
  1663.        The application can configure a clip texture by loading
  1664.        _c_o_n_f_i_g_u_r_a_t_i_o_n _f_i_l_e_s, contains information about the texel
  1665.        data, cliptexture sizes, and texture file names and
  1666.        locations. A configured cliptexture can be used in the scene
  1667.        graph like a normal pfTexture. The application can attach
  1668.        mpcliptextures to cliptextures, and pipes to mpcliptextures
  1669.        automates the cliptexture apply process each frame, and
  1670.        allows cliptexture updates to be done in the application
  1671.        process. Every frame, the application updates the
  1672.        mpcliptexture _c_l_i_p_m_a_p _c_e_n_t_e_r. This can be automated by
  1673.        adding _c_e_n_t_e_r _n_o_d_e_s nodes to the scenegraph.
  1674.  
  1675.        Cliptextures have a load control feature called Dynamic
  1676.        Texture Resolution (DTR). This feature allows clipmaps to be
  1677.        roamed faster than the system bandwidth would normally
  1678.        allow. DTR accomplishes this by improving the order in which
  1679.        tiles are download into image caches, and selectively
  1680.        blurring the cliptexture and adjusting the effective
  1681.        clipsize in order to modulate the cliptextures bandwidth
  1682.        requirements. DTR is controlled through a mode bitmask,
  1683.        which is used to enable or disable various load control
  1684.        features, and by a set of parameters that can be adjusted by
  1685.        the application to tune load control performance.
  1686.  
  1687.        There is a special form of clipmaps, called virtual
  1688.        clipmaps, which can be used to exceed some of the
  1689.        limitations in maximum virtual size and number of levels
  1690.        inherent in the system hardware. Virtual clipmaps trade off
  1691.        larger possible cliptextures against increased complexity,
  1692.        and additional interactions between the cliptexture and the
  1693.        scenegraph. With virtual cliptextues, the cliptexture,
  1694.        itself a virtualization of a MIPmap, is itself virtualized.
  1695.        The physical cliptexture is roamed within a larger virtual
  1696.        cliptexture in three dimensions; s, t, and level of detail
  1697.        (LOD). This roaming is controlled by setting the center and
  1698.        adjusting the virtualLOD offset. The number of physical
  1699.        clipmap levels in use is controlled by adjusting the
  1700.        effective levels parameter. When many levels need to be
  1701.        accessed, the virtuallodoffset and other parameters can be
  1702.        dynamically modified as the scenegraph is traversed, trading
  1703.        off some performance for much wider range of available LOD
  1704.        levels.
  1705.  
  1706.        Man pages to see: pfClipTexture, pfQueue, pfImageTile
  1707.  
  1708.        Demos to check out:
  1709.  
  1710.  
  1711.  
  1712.  
  1713.  
  1714.  
  1715.  
  1716.  
  1717.  
  1718.  
  1719.  
  1720.                                   - 27 -
  1721.  
  1722.  
  1723.  
  1724.                /usr/share/Performer/data/clipdata/hunter/run_hl
  1725.                /usr/share/Performer/data/clipdata/moffett/run_mof
  1726.  
  1727.        Sample programs to check out:
  1728.  
  1729.                /usr/share/Performer/src/pguide/libpr/icache.c
  1730.                /usr/share/Performer/src/pguide/libpr/icache_mwin.c
  1731.                /usr/share/Performer/src/pguide/libpf/cliptex.c
  1732.                /usr/share/Performer/src/sample/C/perfly
  1733.  
  1734.        Utilities to use:
  1735.  
  1736.                /usr/share/Performer/src/libpfutil/cliptexture.c
  1737.                /usr/share/Performer/src/libpfutil/clipcenter.c
  1738.  
  1739.        ClipTexture Texture Data and Configuration Files:
  1740.  
  1741.                /usr/share/Performer/data/clipdata/hunter
  1742.                /usr/share/Performer/data/clipdata/moffett
  1743.                *.ic - image cache configuration files
  1744.                *.ct - cliptexture configuration files
  1745.  
  1746.  
  1747.  
  1748.        6.14.4.2  _V_i_r_t_u_a_l__c_l_i_p_t_e_x_t_u_r_e_s
  1749.  
  1750.        Virtual cliptextures of up to 1<<23 (8 million) texels on a
  1751.        side are supported by IRIS Performer 2.2.  This allows a
  1752.        real cliptextures (currently limited in size by the
  1753.        InfiniteReality hardware to at most 32Kx32K texels) to be
  1754.        embedded in a larger virtual clipmap of up to 8Mx8M texels.
  1755.  
  1756.        The application controls the position of the real
  1757.        cliptexture within the virtual cliptexture by updating the
  1758.        center and the _v_i_r_t_u_a_l _L_O_D _o_f_f_s_e_t. The offset adjusts the
  1759.        real cliptexture in the LOD direction.  The real cliptexture
  1760.        can only occupy positions that are valid subsets of the
  1761.        virtual cliptexture. The number of valid locations can be
  1762.        increased by using less _e_f_f_e_c_t_i_v_e _l_e_v_e_l_s The real
  1763.        cliptexture will automatically be centered around the
  1764.        current center of the virtual cliptexture, which the
  1765.        application sets on a per-frame basis (see above).
  1766.  
  1767.        Utilities are provided for intelligently selecting where to
  1768.        offset the real clipmap within the virtual clipmap each
  1769.        frame.  For details, see the source code for
  1770.        pfuCalcSizeFinestMipLOD in libpfutil, and play with the
  1771.        "Clip LOD Offset" slider in perfly when viewing a clip
  1772.        texture bigger than 32Kx32K.
  1773.  
  1774.  
  1775.  
  1776.  
  1777.  
  1778.  
  1779.  
  1780.  
  1781.  
  1782.  
  1783.  
  1784.  
  1785.  
  1786.                                   - 28 -
  1787.  
  1788.  
  1789.  
  1790.        6.14.4.3  _A_c_t_i_v_e__S_u_r_f_a_c_e__D_e_f_i_n_i_t_i_o_n
  1791.  
  1792.        A pfASD is a pfNode which can handle very large terrain
  1793.        surfaces that are described as multiple LODs.  Active
  1794.        Surface Definition accuratedly describes different portions
  1795.        of the terrain using triangles from different LODs.  The
  1796.        multiple LODs have a coherent subdivision-surfaces-like
  1797.        relationship between the neighboring levels.  pfASD contains
  1798.        a small scene graph that is generated dynamically to reflect
  1799.        the current visible geometry being rendered.
  1800.  
  1801.        These routines implement the Active Surface Definition (ASD)
  1802.        feature.  ASD defines a hierarchical structure that
  1803.        organizes all the LODs of a terrain. At run-time, ASD
  1804.        traverses the structure, selecting triangles from different
  1805.        LODs to render the portion of the terrain that is within a
  1806.        volume of interest. Triangles are rendered either at their
  1807.        pre-stored locations, when they are in a particular LOD
  1808.        range, or at computed morphed locations, when they are
  1809.        within the morphing zone of a LOD range. There will be other
  1810.        ways to evaluate the terrain other than purely range based
  1811.        approach. The way to evaluate each vertex is the "evaluation
  1812.        function".  The evaluation function can be defined as a user
  1813.        call back function, when the default range based evaluation
  1814.        is not appropriate.
  1815.  
  1816.        An example of a user defined callback function can be found
  1817.        in
  1818.  
  1819.                /usr/share/Performer/src/sample/C/asdfly/eval_function.c
  1820.  
  1821.  
  1822.        pfASD has its own thread when user claimed multiprocessing
  1823.        mode, e.g.  PFMP_FORK_COMPUTE. Asychronizely, the evaluation
  1824.        of the structure is done in the thread and the created
  1825.        geometry (active mesh) are merged into the scenegraph
  1826.        internal to pfASD at pfFrame time.  pfASD enlarges the
  1827.        viewing frustum to accommodate the delay of evaluation.
  1828.  
  1829.        The cull of pfASD is handled together with the evaluation.
  1830.        In another word, the gsets that are generated by evaluation
  1831.        is the set of triangles that should be or soon to be
  1832.        visible.
  1833.  
  1834.        pfASD handles multichannel evaluation and ensures that
  1835.        neighboring channels will have consistently connected
  1836.        triangles.  A channel can also share the evaluated active
  1837.        mesh from another channel using pfChannel::ASDattach.  pfASD
  1838.        handles multipipe as well.
  1839.  
  1840.  
  1841.  
  1842.  
  1843.  
  1844.  
  1845.  
  1846.  
  1847.  
  1848.  
  1849.  
  1850.  
  1851.  
  1852.                                   - 29 -
  1853.  
  1854.  
  1855.  
  1856.        6.14.4.4  _F_l_u_x__a_n_d__E_n_g_i_n_e
  1857.  
  1858.        A _p_f_F_l_u_x is a container for holding dynamic data.  It
  1859.        contains multiple buffers of data each associated with a
  1860.        frame number.  This allows multiple processes to each have a
  1861.        copy of the data appropriate to the frame they are working
  1862.        on. A full pfGeoSet can be fluxed pfFlux should be used
  1863.        instead of pfCycleBuffer as they do not require a copy of
  1864.        the data to be done to synchronize the stages of the process
  1865.        pipeline.
  1866.  
  1867.        A _p_f_E_n_g_i_n_e is an object that controls the dynamic data in a
  1868.        pfFlux.  A pfEngine of type PFENG_MORPH associated with a
  1869.        pfFlux replaces a pfMorph node.
  1870.  
  1871.        see _p_f_F_l_u_x, _p_f_E_n_g_i_n_e, _p_f_F_S_C, _p_f_S_w_i_t_c_h and _p_f_L_O_D man pages.
  1872.  
  1873.  
  1874.        6.14.5  _D_i_f_f_e_r_e_n_c_e_s__B_e_t_w_e_e_n__2_._2__a_n_d__2_._1
  1875.  
  1876.  
  1877.        6.14.5.1  _C_l_i_p_M_a_p_p_i_n_g
  1878.  
  1879.        _p_f_I_m_a_g_e_C_a_c_h_e renamed some API calls (the corresponding gets
  1880.        are  not shown)
  1881.  
  1882.  
  1883.                wwwwaaaassss:::: ppppffffIIIImmmmaaaaggggeeeeCCCCaaaacccchhhheeeeOOOOrrrriiiiggggiiiinnnn
  1884.                nnnneeeewwww:::: ppppffffIIIImmmmaaaaggggeeeeCCCCaaaacccchhhheeeeMMMMeeeemmmmRRRReeeeggggiiiioooonnnnOOOOrrrrgggg
  1885.  
  1886.  
  1887.  
  1888.                wwwwaaaassss:::: ppppffffIIIImmmmaaaaggggeeeeCCCCaaaacccchhhheeeeSSSSiiiizzzzeeee
  1889.                nnnneeeewwww:::: ppppffffIIIImmmmaaaaggggeeeeCCCCaaaacccchhhheeeeMMMMeeeemmmmRRRReeeeggggiiiioooonnnnSSSSiiiizzzzeeee
  1890.  
  1891.  
  1892.  
  1893.                wwwwaaaassss:::: ppppffffIIIImmmmaaaaggggeeeeCCCCaaaacccchhhheeeeVVVVaaaalllliiiiddddRRRReeeeggggiiiioooonnnnOOOOrrrriiiiggggiiiinnnn
  1894.                nnnneeeewwww:::: ppppffffIIIImmmmaaaaggggeeeeCCCCaaaacccchhhheeeeTTTTeeeexxxxRRRReeeeggggiiiioooonnnnOOOOrrrrgggg
  1895.  
  1896.  
  1897.  
  1898.                wwwwaaaassss:::: ppppffffIIIImmmmaaaaggggeeeeCCCCaaaacccchhhheeeeVVVVaaaalllliiiiddddRRRReeeeggggiiiioooonnnnSSSSiiiizzzzeeee
  1899.                nnnneeeewwww:::: ppppffffIIIImmmmaaaaggggeeeeCCCCaaaacccchhhheeeeTTTTeeeexxxxRRRReeeeggggiiiioooonnnnSSSSiiiizzzzeeee
  1900.  
  1901.  
  1902.  
  1903.                wwwwaaaassss:::: ppppffffIIIImmmmaaaaggggeeeeCCCCaaaacccchhhheeeeVVVVaaaalllliiiiddddRRRReeeeggggiiiioooonnnnDDDDsssstttt
  1904.                nnnneeeewwww:::: ppppffffIIIImmmmaaaaggggeeeeCCCCaaaacccchhhheeeeTTTTeeeexxxx
  1905.  
  1906.  
  1907.  
  1908.  
  1909.  
  1910.  
  1911.  
  1912.  
  1913.  
  1914.  
  1915.  
  1916.  
  1917.  
  1918.                                   - 30 -
  1919.  
  1920.  
  1921.  
  1922.                wwwwaaaassss:::: ppppffffIIIImmmmaaaaggggeeeeCCCCaaaacccchhhheeeeVVVVaaaalllliiiiddddRRRReeeeggggiiiioooonnnnDDDDssssttttSSSSiiiizzzzeeee
  1923.                nnnneeeewwww:::: ppppffffIIIImmmmaaaaggggeeeeCCCCaaaacccchhhheeeeTTTTeeeexxxxSSSSiiiizzzzeeee
  1924.  
  1925.  
  1926.  
  1927.                wwwwaaaassss:::: ppppffffIIIImmmmaaaaggggeeeeCCCCaaaacccchhhheeeeVVVViiiirrrrttttuuuuaaaallllSSSSiiiizzzzeeee
  1928.                nnnneeeewwww:::: ppppffffIIIImmmmaaaaggggeeeeCCCCaaaacccchhhheeeeIIIImmmmaaaaggggeeeeSSSSiiiizzzzeeee
  1929.  
  1930.  
  1931.  
  1932.                oooobbbbssssoooolllleeeetttteeee:::: ppppffffIIIImmmmaaaaggggeeeeCCCCaaaacccchhhheeeeCCCCeeeennnntttteeeerrrr
  1933.                oooobbbbssssoooolllleeeetttteeee:::: ppppffffIIIImmmmaaaaggggeeeeCCCCaaaacccchhhheeeeMMMMaaaaxxxxUUUUppppddddaaaatttteeeeSSSSiiiizzzzeeee
  1934.  
  1935.  
  1936.  
  1937.                nnnneeeewwww:::: ppppffffIIIImmmmaaaaggggeeeeCCCCaaaacccchhhheeeeCCCCaaaallllccccTTTTeeeexxxxRRRReeeeggggiiiioooonnnn
  1938.                nnnneeeewwww:::: ppppffffIIIImmmmaaaaggggeeeeCCCCaaaacccchhhheeeeCCCCaaaallllccccMMMMeeeemmmmRRRReeeeggggiiiioooonnnn
  1939.  
  1940.  
  1941.        _p_f_Q_u_e_u_e as new functionality
  1942.  
  1943.  
  1944.                nnnneeeewwww:::: ppppffffQQQQuuuueeeeuuuueeeeSSSSoooorrrrttttMMMMooooddddeeee
  1945.                nnnneeeewwww:::: ppppffffQQQQuuuueeeeuuuueeeeSSSSoooorrrrttttFFFFuuuunnnncccc
  1946.                nnnneeeewwww:::: ppppffffQQQQuuuueeeeuuuueeeeIIIInnnnppppuuuuttttRRRRaaaannnnggggeeee
  1947.                nnnneeeewwww:::: ppppffffQQQQuuuueeeeuuuueeeeOOOOuuuuttttppppuuuuttttRRRRaaaannnnggggeeee
  1948.                nnnneeeewwww:::: ppppffffGGGGeeeettttQQQQuuuueeeeuuuueeeeSSSSoooorrrrttttPPPPrrrrooooccccPPPPIIIIDDDD
  1949.  
  1950.  
  1951.        _p_f_I_m_a_g_e_C_a_c_h_e now use sorting queus Image cache configuration
  1952.        files have a version2.0 format. The parser will run with
  1953.        either format. The new format is a little more robust and
  1954.        easier to use. The parser also now calls separate pfutil
  1955.        functions that do the creation and configuration work. This
  1956.        will make it easier to create custom configuration routines.
  1957.  
  1958.        The configuration files now support relative pathnames.
  1959.        Cliptexture configuration files can now be created that
  1960.        don't need image cache configuration files.
  1961.  
  1962.  
  1963.        6.14.5.2  _A_c_t_i_v_e__S_u_r_f_a_c_e__D_e_f_i_n_i_t_i_o_n
  1964.  
  1965.        _l_i_b_p_f_s _n_o _l_o_n_g_e_r _e_x_i_s_t_s. You should make sure you no longer
  1966.        link with it. pfTerrain no longer exists either.  All
  1967.        PFTERRAIN_ tokens have been renamed PFASD_.  Aligning object
  1968.        to pfASD uses pfFlux and pfEngine.
  1969.  
  1970.  
  1971.            ppppffffAAAASSSSDDDDGGGGSSSSttttaaaatttteeee((((ppppffffAAAASSSSDDDD**** ____aaaassssdddd,,,, ppppffffGGGGeeeeooooSSSSttttaaaatttteeee ****ggggssss))))
  1972.  
  1973.  
  1974.  
  1975.  
  1976.  
  1977.  
  1978.  
  1979.  
  1980.  
  1981.  
  1982.  
  1983.  
  1984.                                   - 31 -
  1985.  
  1986.  
  1987.  
  1988.        is now
  1989.  
  1990.  
  1991.            ppppffffAAAASSSSDDDDGGGGSSSSttttaaaatttteeeessss((((ppppffffAAAASSSSDDDD**** ____aaaassssdddd,,,, ppppffffGGGGeeeeooooSSSSttttaaaatttteeee ********ggggssss,,,, iiiinnnntttt nnnnuuuummmm))))
  1992.  
  1993.        It is important that when you port to this new api you use
  1994.        pfMalloc to allocate the array of pfGeoState pointers.
  1995.  
  1996.        So:
  1997.  
  1998.  
  1999.                ppppffffAAAASSSSDDDDGGGGSSSSttttaaaatttteeee((((aaaassssdddd,,,, ggggssss))));;;;
  2000.  
  2001.        Should become:
  2002.  
  2003.  
  2004.                {{{{
  2005.                   ppppffffGGGGeeeeooooSSSSeeeetttt ********ggggssssssss;;;;
  2006.                   ggggssssssss ==== ((((ppppffffGGGGeeeeooooSSSSeeeetttt ********))))ppppffffMMMMaaaalllllllloooocccc((((ssssiiiizzzzeeeeooooffff((((ppppffffGGGGeeeeooooSSSSeeeetttt********))))****1111,,,,
  2007.                                ppppffffGGGGeeeettttSSSShhhhaaaarrrreeeeddddAAAArrrreeeennnnaaaa(((())))))));;;;
  2008.                   ggggssssssss[[[[0000]]]] ==== ggggssss;;;;
  2009.                   ppppffffAAAASSSSDDDDGGGGSSSSttttaaaatttteeeessss((((aaaassssdddd,,,, ggggssssssss,,,, 1111))));;;;
  2010.                }}}}
  2011.  
  2012.        PFTERRAIN constants have become PFASD constants pfs prefix
  2013.        has become pfASD pfsFace data structure has become pfASDFace
  2014.        and the field names have been changed to properly reflect
  2015.        the functionality.
  2016.  
  2017.        A current version of the Muligen loader is supplied to
  2018.        handle these changes
  2019.  
  2020.        New sample programs including examples of aligning features
  2021.        and moving objects to ASD geometry.
  2022.  
  2023.                /usr/share/Performer/src/pguide/libpf/C/ASD_align.c
  2024.  
  2025.        New sample program that demonstrates the pfASD data
  2026.        structure
  2027.  
  2028.                /usr/share/Performer/src/pguide/libpf/C++/simpleASD.C
  2029.  
  2030.  
  2031.        pfASD can be paged in as simle areal blocks, as handled by
  2032.        Multigen CAT feature.
  2033.  
  2034.        pfASD also supports a multi-resolution paging scheme, very
  2035.        similar to clipmap paging. An example of the construction of
  2036.        pfASD from a set of uniform elevation data  can be found in
  2037.  
  2038.  
  2039.  
  2040.  
  2041.  
  2042.  
  2043.  
  2044.  
  2045.  
  2046.  
  2047.  
  2048.  
  2049.  
  2050.                                   - 32 -
  2051.  
  2052.  
  2053.  
  2054.                /usr/share/Performer/src/lib/libpfdu/pfdBuildASD.c
  2055.  
  2056.        Inside the same file, you can find routines that constructs
  2057.        paging ASD tiles from a fully built ASD structure. Please
  2058.        notice that the builder is for demonstration purposes
  2059.        mainly. The algorithm used is not sophisticated enough to
  2060.        provent terrain from visible morphing distortion during
  2061.        real-time fly through. The demo "yosemite" provided on 2.2
  2062.        demo CD is constructed using CAT feature in Multigen.
  2063.  
  2064.        Paging construction example can be found in
  2065.  
  2066.                /usr/share/Performer/src/pguide/libpf/C/buildarcinfo.c
  2067.                /usr/share/Performer/src/pguide/libpf/C/buildbw.c
  2068.                /usr/share/Performer/src/pguide/libpf/C/builddem.c
  2069.                /usr/share/Performer/src/pguide/libpf/C/builddted.c
  2070.  
  2071.        Executing the command, e.g.
  2072.  
  2073.                buildbw elevation.bw bw/tile bw/config bw/page
  2074.  
  2075.        will put a set of paging tiles under the directory bw, with
  2076.        prefix "tile" as their file names. Once you decide on how
  2077.        many extra tiles to page on each LOD based on LODRange as
  2078.        well as the paging delay, you MUST process the tiles one
  2079.        more time into a fast paging binary format before feeding it
  2080.        into a paging pfASD node.
  2081.  
  2082.        The second pass paging data construction can be found in
  2083.  
  2084.                /usr/share/Performer/src/pguide/libpf/C/convasd.c
  2085.  
  2086.        For example,
  2087.  
  2088.                convasd bw/config bw/page
  2089.  
  2090.        will process the tiles.  The final step is to hand all the
  2091.        attributes defined in the config file and page file to pfASD
  2092.        by calling
  2093.  
  2094.                pfdLoadConfig(config, page);
  2095.  
  2096.  
  2097.  
  2098.        6.14.5.3  _O_p_e_n_G_L__V_e_r_t_e_x__A_r_r_a_y_s
  2099.  
  2100.        The OpenGL _V_e_r_t_e_x_A_r_r_a_y extension is supported by IRIS
  2101.        Performer as an optimized way to send formatted data to the
  2102.        graphics pipeline, reducing the host interface.
  2103.  
  2104.        Vertex arrays use a new pfGSetAttr list, PFGS_PACKED_ATTRS,
  2105.  
  2106.  
  2107.  
  2108.  
  2109.  
  2110.  
  2111.  
  2112.  
  2113.  
  2114.  
  2115.  
  2116.                                   - 33 -
  2117.  
  2118.  
  2119.  
  2120.        that includes a separate copy of the vertex attribute data
  2121.        packed into a single non-indexed array.  Your vertex
  2122.        coordinates may optionally be in this packed array.  A
  2123.        sample program that demonstrates the use of vertex arrays on
  2124.        pfGeoSets is in:
  2125.  
  2126.                /usr/share/Performer/src/pguide/libpr/packedattrs.c
  2127.  
  2128.        Additionally, there is a utility traversal,
  2129.        pfuTravCreateVertArrays, that will traverse the scene graph
  2130.        and create vertex arrays for the pfGeoSets and optionally
  2131.        pfDelete the other redundant attribute arrays.  The utility
  2132.        routines used by this traversal to actually pack the
  2133.        pfGeoSet data is  pfuFillGSetVertArray().  This traversal
  2134.        can be invoked on the Perfly sample application with the -v
  2135.        # option where # is 1 or 2 to select one of two packed
  2136.        formats of with or without the vertices copied into the
  2137.        vertex array, respectively.
  2138.  
  2139.  
  2140.        6.14.5.4  _O_p_e_n_G_L__s_p_l_i_n_e__F_o_g
  2141.  
  2142.        InfiniteReality supports the specification of a fog function
  2143.        so Spline Fog support for OpenGL has been added to IRIS
  2144.        Performer and will be available on machines that support it.
  2145.  
  2146.  
  2147.        6.14.5.5  _T_F_a_n_s
  2148.  
  2149.        IRIS Performer 2.2 supports Triangle Fans in a pfGeoSets
  2150.        when using OpenGL
  2151.  
  2152.  
  2153.        6.14.5.6  _A_s_y_n_c_h_r_o_n_o_u_s__D_y_n_a_m_i_c__D_a_t_a
  2154.  
  2155.        IRIS Performer 2.2 supports truly asynchronous dynamic data
  2156.        with _p_f_F_l_u_x.  Data for geometry attributes in pfGeoSets and
  2157.        fields in various pfNodes can be computed in fully
  2158.        asynchronous processes and store in a pfFlux buffer.  pfFlux
  2159.        will manage the the hookup, data exclusion, and frame
  2160.        management accurate book-keeping.  pfFluxes can be
  2161.        explicitly driven by _p_f_E_n_g_i_n_e_s for defining the functions
  2162.        that generate the dynamic data.
  2163.  
  2164.        pfGeoSets themselves can be fluxed and fluxed pfGeoSets can
  2165.        be given to a pfGeode directly.
  2166.  
  2167.        pfEngines can be used to control the data in a flux. A
  2168.        complete graph of pfEngines and pfFlux can be done to
  2169.        control the dynamic behavior of a database. Both pfEngines
  2170.        and pfFluxes are stored in the performer binary file format
  2171.  
  2172.  
  2173.  
  2174.  
  2175.  
  2176.  
  2177.  
  2178.  
  2179.  
  2180.  
  2181.  
  2182.                                   - 34 -
  2183.  
  2184.  
  2185.  
  2186.        (pfb), even external functions used by pfEngines can be
  2187.        registers into the pfb and the right DSO will automatically
  2188.        be loaded when the pfb file will be used in Performer.
  2189.  
  2190.  
  2191.        6.14.5.7  _L_i_g_h_t__P_o_i_n_t
  2192.  
  2193.        A new light point process can be forked off and use a cpu to
  2194.        do the _p_f_L_P_o_i_n_t_S_t_a_t_e computation instead of taking time of
  2195.        the Draw Process.  The light point process is synchronous to
  2196.        the Draw process, and also support Calligraphic Light points
  2197.        when the Calligraphic Board and Projector are hooked to the
  2198.        system. To learn more about raster and calligraphic lights
  2199.        see the pfLPointState and _p_f_C_a_l_l_i_g_r_a_p_h_i_c man pages, as well
  2200.        as the pfChannel man pages to see how the light point
  2201.        process works.
  2202.  
  2203.  
  2204.        6.14.5.8  _N_e_w__l_o_a_d_e_r_s
  2205.  
  2206.           +o Loaders for creating pfASD structures from elevation
  2207.             data are now include in IRIS Performer 2.2
  2208.             _l_i_b_p_f_d_b/_l_i_b_p_f_d_e_m - This loader handles a variety of the
  2209.             USGS DEM elevation data products, including the common
  2210.             7.5 minute (1:24,000) and 1 degree (1:250,000) DEM
  2211.             files.  _l_i_b_p_f_d_b/_l_i_b_p_f_d_t_e_d - This loader handles DMA
  2212.             DTED Level 1 and 2 elevation data products.
  2213.             _l_i_b_p_f_d_b/_l_i_b_p_f_a_r_c_i_n_f_o - This loader handles elevation
  2214.             data files in the simple ARC/INFO ASCII GRID export
  2215.             format.  _l_i_b_p_f_d_b/_l_i_b_p_f_e_v_t - This loader reads data in
  2216.             the temporary ".evt" binary format.
  2217.             The loaders read the elevation data from the file and
  2218.             construct an appropriate pfASD node structure.  The
  2219.             origin coordinates of the created pfASD node will be
  2220.             set to the southwest corner, zero altitude point of the
  2221.             elevation data area.  The data will be oriented in the
  2222.             XY plane for elevation data specified in planar
  2223.             coordinates (such as UTM), or oriented properly on the
  2224.             earth ellipsoid for data specified in geodetic
  2225.             coordinates (Z-axis towards North Pole, X-axis defined
  2226.             by the intersection of the prime meridian and
  2227.             equatorial planes).  Use pfdBuildASD to indicate the
  2228.             levels of detail you wish to build.  That is the last
  2229.             parameter in pfdBuildASD().
  2230.  
  2231.             The function "libpfdu/pfdBuildASD()" can be used to
  2232.             construct pfASD structures for elevation data not
  2233.             handled by the above loaders.  There are support for
  2234.             building paging tiles in pfdBuildASD(). It is not
  2235.             turned on by default. Set the PAGING constant in
  2236.             pfdBuildASD.c to 1 if you want to experiment with
  2237.  
  2238.  
  2239.  
  2240.  
  2241.  
  2242.  
  2243.  
  2244.  
  2245.  
  2246.  
  2247.  
  2248.                                   - 35 -
  2249.  
  2250.  
  2251.  
  2252.             paging pfASD tiles.
  2253.  
  2254.  
  2255.           +o A VRML 2.0 loader is included. This loader is a gift
  2256.             from DrAW Computing Associates and will successfully
  2257.             the geometry and texture of many VRML2.0 files. To have
  2258.             more VRML 2.0 support, such as Routes, JAVA,
  2259.             saveToVrml, html direct access from performer, or to
  2260.             report any problem with the VRML 2.0 loader you will
  2261.             have to contact them directly at info@openworlds.com.
  2262.             See the demos under openworlds in the Friend of
  2263.             Performer 2.2 CD.  Note that VRML 1.0 files are not
  2264.             supported by this loader. Previously the case, so you
  2265.             have either to convert your VRML1.0 files to VRML2.0,
  2266.             or to explicitly name your files .iv so the inventor
  2267.             loader will be used in place of the VRML 2.0 loader.
  2268.  
  2269.  
  2270.           +o A OpenGL Optimizer binary file loader (csb) is part of
  2271.             IRIS Performer 2.2 distribution. This allow exchange of
  2272.             files in between the two products as OpenGL Optimizer
  2273.             reads IRIS Performer binary files (pfb). Note that the
  2274.             pfb loader for Optimizer has a problem that changes all
  2275.             opaque polygons to fully transparent and vice-versa.
  2276.             This will be fixed, and a new pfb loader for OpenGL
  2277.             Optimizer will be available on the Web. (see section 4
  2278.             of release note)
  2279.  
  2280.  
  2281.  
  2282.        6.14.5.9  _C_o_p_l_a_n_a_r__g_e_o_m_e_t_r_y
  2283.  
  2284.        Layer and Decal geometry may now use the new OpenGL
  2285.        reference plane.  Reference planes may be specified on
  2286.        pfGeoSets, pfGeoStates, and in the global state.  See the
  2287.        pfGeoSet and pfDecal, and pfGeoState reference pages for
  2288.        more information.
  2289.  
  2290.  
  2291.        6.14.5.10  _T_e_x_t_u_r_e__m_a_t_r_i_c_e_s
  2292.        Texture matrices may now be specified on pfGeoStates.  See
  2293.        the pfGeoState reference page for more information.
  2294.  
  2295.  
  2296.        6.14.5.11  _T_r_a_v_e_r_s_a_l_s
  2297.        libpfutil traversal, pfuTravCompileDList, traversal for
  2298.        traversing an entire scene graph and creating display lists
  2299.        for all pfGeoSets.  This is to be used in combination with
  2300.        pfuTravDListDraw and is useful for compiling and pre-
  2301.        downloading display lists on InfiniteReality.
  2302.  
  2303.  
  2304.  
  2305.  
  2306.  
  2307.  
  2308.  
  2309.  
  2310.  
  2311.  
  2312.  
  2313.  
  2314.                                   - 36 -
  2315.  
  2316.  
  2317.  
  2318.        6.14.5.12  _V_i_d_e_o__t_e_x_t_u_r_i_n_g
  2319.  
  2320.        There is one main sample program for video texturing:
  2321.  
  2322.           /usr/share/Performer/src/pguide/libpf/C/movietex.c
  2323.  
  2324.        a multiprocessing example.  Note that all video
  2325.        initialization, including the creation of video library
  2326.        resources, is done in the draw process, as required by the
  2327.        video library. The program has #define switches for
  2328.        compilation on IRIX 6.2 or IRIX 6.5 and supports DIVO,
  2329.        Sirius, OCTANE, and O2 video options.  Movitex.c uses
  2330.        features added in Performer 2.2: special pfTexture LOAD
  2331.        source parameters for specifying dmedia buffers or the video
  2332.        library server, path and drain, as well as the texture
  2333.        matrix that can be specified on a pfGeoState with the
  2334.        PFSTATE_TEXMAT attribute for transforming texture
  2335.        coordinates int the proper area of a texture receiving video
  2336.        input.
  2337.  
  2338.        An old Sirius example has been retained in
  2339.        /usr/share/Performer/src/pguide/libpr/C/siriusvidtex.c.
  2340.  
  2341.  
  2342.        6.14.5.13  _T_e_x_t_u_r_e__L_O_D__o_b_j_e_c_t
  2343.  
  2344.        New pfTexLOD object for controlling LOD of textures.
  2345.        pfTexLOD is a new state attribute used to control the use of
  2346.        levels of detail of a pfTexture.  The levels of detail
  2347.        accessed can be limited by setting the LOD range and the
  2348.        computation of the current LOD value can be biased.  These
  2349.        controls are useful in conjunction with dynamic texture
  2350.        loading where the accessed levels can be limited to the
  2351.        valid levels and for artificially blurring or sharpening a
  2352.        texture.
  2353.  
  2354.  
  2355.        6.14.5.14  _N_e_w__f_a_s_t__i_m_a_g_e__f_i_l_e__f_o_r_m_a_t
  2356.  
  2357.        There is now the pfi fast image file loader to complement
  2358.        pfb.  pfi files are hardware-ready fast loading image files
  2359.        that may contain MIPmaps for textures and multiple complete
  2360.        textures.
  2361.  
  2362.        /usr/share/Performer/src/sample/pfconv.c
  2363.  
  2364.        can convert a database to use pfi files for its textures. In
  2365.        addition, there is a
  2366.  
  2367.        /usr/share/Performer/src/sample/pficonv.c
  2368.  
  2369.  
  2370.  
  2371.  
  2372.  
  2373.  
  2374.  
  2375.  
  2376.  
  2377.  
  2378.  
  2379.  
  2380.                                   - 37 -
  2381.  
  2382.  
  2383.  
  2384.        for converting .rgb files to pfi files and generating
  2385.        MIPmaps.  Look at the data/town/town_ogl_pfi.pfb database.
  2386.  
  2387.  
  2388.        6.14.5.15  _p_f_C_h_a_n_n_e_l
  2389.        Here are the additional C++ member functions added in
  2390.        Performer 2.2 to those already provided in IRIS Performer
  2391.        2.1 for the pfChannel class. Each C++ function has a
  2392.        corresponding C function, and all are fully described in the
  2393.        IRIS Performer 2.2 C and C++ Reference Pages.
  2394.  
  2395.  
  2396.            ggggeeeettttFFFFrrrraaaammmmeeeePPPPVVVVCCCChhhhaaaannnn
  2397.            sssseeeettttOOOOuuuuttttppppuuuuttttVVVViiiieeeewwwwppppoooorrrrtttt
  2398.            sssseeeettttCCCCaaaalllllllliiiiggggEEEEnnnnaaaabbbblllleeee
  2399.            ggggeeeettttCCCCaaaalllllllliiiiggggEEEEnnnnaaaabbbblllleeee
  2400.            sssseeeettttCCCCaaaalllllllliiiigggg
  2401.            ggggeeeettttCCCCaaaalllllllliiiigggg
  2402.            ggggeeeettttCCCCuuuurrrrCCCCaaaalllllllliiiigggg
  2403.            ggggeeeettttFFFFrrrreeeeeeeeBBBBiiiinnnn
  2404.            AAAASSSSDDDDAAAAttttttttaaaacccchhhh
  2405.            AAAASSSSDDDDddddeeeettttaaaacccchhhh
  2406.  
  2407.        6.14.5.16  _p_f_D_i_s_p_L_i_s_t
  2408.  
  2409.        This is the additional C++ member function added in
  2410.        Performer 2.2 to those already provided in IRIS Performer
  2411.        2.1 for the pfDispList class. This function allows the
  2412.        contents of one IRIS Performer pfDispList to be appended to
  2413.        a second pfDispList, supporting the merge of independent
  2414.        pfDispLists.  The _p_f_D_i_s_p_L_i_s_t::_a_p_p_e_n_d C++ function has a
  2415.        corresponding C function (_p_f_A_p_p_e_n_d_D_L_i_s_t), and both are fully
  2416.        described in the IRIS Performer 2.2 C and C++ Reference
  2417.        Pages.
  2418.  
  2419.  
  2420.            ggggeeeettttGGGGLLLLHHHHaaaannnnddddlllleeee
  2421.            sssseeeettttMMMMooooddddeeee
  2422.            ccccoooommmmppppiiiilllleeee
  2423.            pppprrrreeeepppprrrroooocccceeeessssssss
  2424.  
  2425.        6.14.5.17  _p_f_Q_u_e_u_e
  2426.  
  2427.        Here are the additional C++ member functions added in
  2428.        Performer 2.2 to those already provided in IRIS Performer
  2429.        2.1 for the pfQueue class.  These new functions add support
  2430.        for having a sort process that will sort the items in the
  2431.        queue.  Each C++ function has a corresponding C function,
  2432.        and all are fully described in the IRIS Performer 2.2 C and
  2433.        C++ Reference Pages.
  2434.  
  2435.  
  2436.  
  2437.  
  2438.  
  2439.  
  2440.  
  2441.  
  2442.  
  2443.  
  2444.  
  2445.  
  2446.                                   - 38 -
  2447.  
  2448.  
  2449.  
  2450.            ggggeeeettttEEEElllleeeemmmmeeeennnnttttSSSSiiiizzzzeeee
  2451.            sssseeeettttSSSSoooorrrrttttFFFFuuuunnnncccc
  2452.            ggggeeeettttSSSSoooorrrrttttFFFFuuuunnnncccc
  2453.            ggggeeeettttSSSSoooorrrrttttMMMMooooddddeeee
  2454.            sssseeeettttIIIInnnnppppuuuuttttRRRRaaaannnnggggeeee
  2455.            ggggeeeettttIIIInnnnppppuuuuttttRRRRaaaannnnggggeeee
  2456.            ggggeeeettttOOOOuuuuttttppppuuuuttttRRRRaaaannnnggggeeee
  2457.            ggggeeeettttSSSSoooorrrrttttPPPPrrrrooooccccPPPPIIIIDDDD
  2458.            iiiinnnnsssseeeerrrrttttFFFFrrrroooonnnntttt
  2459.            aaaatttttttteeeemmmmppppttttRRRReeeemmmmoooovvvveeee
  2460.            ssssiiiiggggnnnnaaaallllAAAAllllllllSSSSeeeerrrrvvvviiiicccceeeePPPPrrrrooooccccssss
  2461.            nnnnoooottttiiiiffffyyyySSSSoooorrrrttttPPPPrrrroooocccc
  2462.  
  2463.        6.14.5.18  _p_f_I_m_a_g_e_T_i_l_e
  2464.  
  2465.        Here are the additional C++ member functions added in
  2466.        Performer 2.2 to those already provided in IRIS Performer
  2467.        2.1 for the pfQueue class.  Each C++ function has a
  2468.        corresponding C function, and all are fully described in the
  2469.        IRIS Performer 2.2 C and C++ Reference Pages.
  2470.  
  2471.  
  2472.           sssseeeettttMMMMeeeemmmmQQQQuuuueeeeuuuueeee
  2473.           ggggeeeettttMMMMeeeemmmmQQQQuuuueeeeuuuueeee
  2474.           iiiissssLLLLooooaaaaddddiiiinnnngggg
  2475.           sssseeeettttPPPPrrrriiiioooorrrriiiittttyyyy
  2476.           ggggeeeettttPPPPrrrriiiioooorrrriiiittttyyyy
  2477.           sssseeeettttIIIImmmmaaaaggggeeeeCCCCaaaacccchhhheeee
  2478.           ggggeeeettttIIIImmmmaaaaggggeeeeCCCCaaaacccchhhheeee
  2479.           sssseeeettttTTTTiiiilllleeeeIIIInnnnddddeeeexxxx
  2480.           ggggeeeettttTTTTiiiilllleeeeIIIInnnnddddeeeexxxx
  2481.           sssseeeettttFFFFiiiilllleeeeNNNNaaaammmmeeeeFFFFuuuunnnncccc
  2482.           ggggeeeettttFFFFiiiilllleeeeNNNNaaaammmmeeeeFFFFuuuunnnncccc
  2483.           RRRReeeeaaaaddddDDDDiiiirrrreeeecccctttt
  2484.           RRRReeeeaaaaddddNNNNoooorrrrmmmmaaaallll
  2485.  
  2486.        6.14.5.19  _p_f_C_l_i_p_T_e_x_t_u_r_e
  2487.  
  2488.        Here are the additional C++ member functions added in
  2489.        Performer 2.2 to those already provided in IRIS Performer
  2490.        2.1 for the pfQueue class.  New functions deal with DTR,
  2491.        which is a tight control on how much time you want to
  2492.        allocate in the DrawProcess to dynamically load the texture
  2493.        versus drawing polygons, and control of Virtual (bigger)
  2494.        clip textures.  Each C++ function has a corresponding C
  2495.        function, and all are fully described in the IRIS Performer
  2496.        2.2 C and C++ Reference Pages.
  2497.  
  2498.  
  2499.            ggggeeeettttCCCCuuuurrrrCCCCeeeennnntttteeeerrrr
  2500.            sssseeeettttVVVViiiirrrrttttuuuuaaaallllLLLLOOOODDDDOOOOffffffffsssseeeetttt
  2501.  
  2502.  
  2503.  
  2504.  
  2505.  
  2506.  
  2507.  
  2508.  
  2509.  
  2510.  
  2511.  
  2512.                                   - 39 -
  2513.  
  2514.  
  2515.  
  2516.            ggggeeeettttVVVViiiirrrrttttuuuuaaaallllLLLLOOOODDDDOOOOffffffffsssseeeetttt
  2517.            sssseeeettttNNNNuuuummmmEEEEffffffffeeeeccccttttiiiivvvveeeeLLLLeeeevvvveeeellllssss
  2518.            ggggeeeettttNNNNuuuummmmEEEEffffffffeeeeccccttttiiiivvvveeeeLLLLeeeevvvveeeellllssss
  2519.            sssseeeettttNNNNuuuummmmAAAAllllllllooooccccaaaatttteeeeddddLLLLeeeevvvveeeellllssss
  2520.            ggggeeeettttNNNNuuuummmmAAAAllllllllooooccccaaaatttteeeeddddLLLLeeeevvvveeeellllssss
  2521.            ggggeeeettttOOOOffffffffsssseeeetttt
  2522.            sssseeeettttTTTTeeeexxxxLLLLooooaaaaddddTTTTiiiimmmmeeee
  2523.            ggggeeeettttTTTTeeeexxxxLLLLooooaaaaddddTTTTiiiimmmmeeee
  2524.            sssseeeettttMMMMaaaasssstttteeeerrrr
  2525.            ggggeeeettttMMMMaaaasssstttteeeerrrr
  2526.            ggggeeeettttSSSSllllaaaavvvveeee
  2527.            sssseeeettttMMMMiiiinnnnCCCClllliiiippppSSSSiiiizzzzeeeeRRRRaaaattttiiiioooo
  2528.            ggggeeeettttMMMMiiiinnnnCCCClllliiiippppSSSSiiiizzzzeeeeRRRRaaaattttiiiioooo
  2529.            sssseeeettttDDDDTTTTRRRRMMMMooooddddeeee
  2530.            ggggeeeettttDDDDTTTTRRRRMMMMooooddddeeee
  2531.            ggggeeeettttMMMMiiiinnnnDDDDTTTTRRRRLLLLOOOODDDD
  2532.            ggggeeeettttDDDDTTTTRRRRFFFFaaaaddddeeeeCCCCoooouuuunnnntttt
  2533.            sssseeeettttDDDDTTTTRRRRBBBBlllluuuurrrrMMMMaaaarrrrggggiiiinnnn
  2534.            ggggeeeettttDDDDTTTTRRRRBBBBlllluuuurrrrMMMMaaaarrrrggggiiiinnnn
  2535.            sssseeeettttNNNNuuuummmmEEEEffffffffeeeeccccttttiiiivvvveeeeLLLLeeeevvvveeeellllssssLLLLiiiimmmmiiiitttt
  2536.            ggggeeeettttNNNNuuuummmmEEEEffffffffeeeeccccttttiiiivvvveeeeLLLLeeeevvvveeeellllssssLLLLiiiimmmmiiiitttt
  2537.            sssseeeettttMMMMiiiinnnnLLLLOOOODDDDLLLLiiiimmmmiiiitttt
  2538.            ggggeeeettttMMMMiiiinnnnLLLLOOOODDDDLLLLiiiimmmmiiiitttt
  2539.            sssseeeettttLLLLOOOODDDDBBBBiiiiaaaassssLLLLiiiimmmmiiiitttt
  2540.            ggggeeeettttLLLLOOOODDDDBBBBiiiiaaaassssLLLLiiiimmmmiiiitttt
  2541.            sssseeeettttLLLLOOOODDDDRRRRaaaannnnggggeeee
  2542.            ggggeeeettttLLLLOOOODDDDRRRRaaaannnnggggeeee
  2543.            ggggeeeettttCCCCuuuurrrrLLLLOOOODDDDRRRRaaaannnnggggeeee
  2544.            sssseeeettttLLLLOOOODDDDBBBBiiiiaaaassss
  2545.            ggggeeeettttLLLLOOOODDDDBBBBiiiiaaaassss
  2546.            ggggeeeettttCCCCiiiirrrrLLLLOOOODDDDBBBBiiiiaaaassss
  2547.            aaaappppppppllllyyyyMMMMeeeemmmmRRRReeeegggg
  2548.            aaaappppppppllllyyyyTTTTeeeexxxxRRRReeeegggg
  2549.            uuuuppppddddaaaatttteeeeMMMMeeeemmmmTTTTeeeegggg
  2550.            uuuuppppddddaaaatttteeeeTTTTeeeexxxxRRRReeeegggg
  2551.            uuuuppppddddaaaatttteeee
  2552.            iiiinnnnvvvvaaaalllliiiiddddaaaatttteeee
  2553.            aaaappppppppllllyyyyVVVViiiirrrrttttuuuuaaaallllPPPPaaaarrrraaaammmmssss
  2554.            aaaappppppppllllyyyyCCCCeeeennnntttteeeerrrr
  2555.            iiiissssVVVViiiirrrrttttuuuuaaaallll
  2556.  
  2557.        6.15  _D_i_f_f_e_r_e_n_c_e_s _b_e_t_w_e_e_n _I_R_I_S _P_e_r_f_o_r_m_e_r _2._0 _a_n_d _p_r_e_v_i_o_u_s
  2558.              _r_e_l_e_a_s_e_s
  2559.  
  2560.        This section elucidates the changes and enhancements between
  2561.        the prior IRIS Performer 2.0 release and the even older IRIS
  2562.        Performer 1.2 release. Since all the 2.0 features are
  2563.        included in 2.2 this concerns porting from 1.2 to 2.2 as
  2564.        well.
  2565.  
  2566.  
  2567.  
  2568.  
  2569.  
  2570.  
  2571.  
  2572.  
  2573.  
  2574.  
  2575.  
  2576.  
  2577.  
  2578.                                   - 40 -
  2579.  
  2580.  
  2581.  
  2582.        If you are new to IRIS Performer or if you have already
  2583.        converted your applications to the more recent 2.0 release
  2584.        you can skip this section, since the information contained
  2585.        here is provided merely to ease porting efforts for older
  2586.        applications. These features are also described in the the
  2587.        IRIS Performer Programming Guide.
  2588.  
  2589.  
  2590.        6.15.1  _N_e_w__F_e_a_t_u_r_e_s
  2591.  
  2592.        6.15.1.1  _S_u_p_p_o_r_t__f_o_r__O_p_e_n_G_L
  2593.        Performer 2.0 includes separate sets of libraries for
  2594.        supporting IRIS GL or OpenGL interfaces. These libraries
  2595.        have GL-dependent suffixes to indicate their type: IRIS
  2596.        GL=_igl and OpenGL=_ogl
  2597.  
  2598.            IIIIRRRRIIIISSSS GGGGLLLL:::: lllliiiibbbbppppffff____iiiiggggllll....ssssoooo
  2599.  
  2600.            OOOOppppeeeennnnGGGGLLLL:::: lllliiiibbbbppppffff____ooooggggllll....ssssoooo
  2601.  
  2602.        Porting an IRIS Performer application from IRIS GL to OpenGL
  2603.        should require very little work.  There are a couple of
  2604.        isolated routine changes (see API changes below).  The main
  2605.        work will be in porting an application IRIS GL code in user
  2606.        draw callbacks and in porting the windowing and event
  2607.        handling to X.  For porting windowing code, pfWindows and
  2608.        pfPipeWindows (libpr and libpf, respectively) provide a GL
  2609.        independent windowing environment.  Libpfutil provides GL-
  2610.        input handling utilities for libpf applications using
  2611.        pfPipeWindows (pfuInitInput()).  The sample programs
  2612.        installed in
  2613.  
  2614.            ////uuuussssrrrr////sssshhhhaaaarrrreeee////PPPPeeeerrrrffffoooorrrrmmmmeeeerrrr////ssssrrrrcccc////ppppgggguuuuiiiiddddeeee////{{{{lllliiiibbbbpppprrrr,,,,lllliiiibbbbppppffff}}}}////pppprrrrooooggggssss
  2615.  
  2616.        also demonstrate comparative X vs GL input handling.
  2617.  
  2618.        When compiling for IRIS GL, use '-DIRISGL' on the command
  2619.        line to include the IRIS GL versions of the Performer header
  2620.        files.
  2621.  
  2622.  
  2623.        6.15.1.2  _6_4_-_b_i_t__a_d_d_r_e_s_s__s_p_a_c_e__s_u_p_p_o_r_t
  2624.  
  2625.        6.15.1.3  _P_e_r_f_o_r_m_e_r__E_n_v_i_r_o_n_m_e_n_t__V_a_r_i_a_b_l_e_s__a_n_d__D_S_O_s
  2626.        Performer now robustly supports the notion of separate run-
  2627.        time file loaders as DSO's (Dynamic Shared Objects).  Thus,
  2628.        the generic utility method for opening a file now differs
  2629.        considerably - the extension of the filename is used to
  2630.        determine the name of shared object to load as well as the
  2631.        function within that shared library to call.  Two new
  2632.        environment variables exist to help locate these dynamic
  2633.  
  2634.  
  2635.  
  2636.  
  2637.  
  2638.  
  2639.  
  2640.  
  2641.  
  2642.  
  2643.  
  2644.                                   - 41 -
  2645.  
  2646.  
  2647.  
  2648.        shared object libraries at run-time:
  2649.  
  2650.           +o PFLD_LIBRARY_PATH Specifies a colon separated list of
  2651.             directories where Performer should look for dynamic
  2652.             objects...
  2653.  
  2654.           +o PFHOME Specifies the root Performer directory (the root
  2655.             used to install Performer).  This is used such that
  2656.             various code in the libraries can look relative to this
  2657.             top level such as $PFHOME/usr/lib/libpfdb might be a
  2658.             location where dso's would live.  In this way a
  2659.             consistent tree structure might be maintained
  2660.             regardless of Performers PFHOME directory.  (This is
  2661.             useful when using Performer installed on another
  2662.             automounted machine for instance - setenv PFHOME
  2663.             /hosts/remote_machine/)
  2664.  
  2665.  
  2666.        6.15.1.4  _C_+_+__A_P_I
  2667.        When compiling programs using Performer's C++ API, you need
  2668.        to directly include the class header files from
  2669.  
  2670.            ////uuuussssrrrr////iiiinnnncccclllluuuuddddeeee////PPPPeeeerrrrffffoooorrrrmmmmeeeerrrr////pppprrrr
  2671.  
  2672.        and
  2673.  
  2674.            ////uuuussssrrrr////iiiinnnncccclllluuuuddddeeee////PPPPeeeerrrrffffoooorrrrmmmmeeeerrrr////ppppffff....
  2675.  
  2676.        6.15.1.5  _C_o_m_p_i_l_i_n_g _P_e_r_f_o_r_m_e_r _1._2 _C++ _a_p_p_l_i_c_a_t_i_o_n_s _w_i_t_h
  2677.        _P_e_r_f_o_r_m_e_r _2._0   With Performer 2.0, compiling a Performer
  2678.        application with the C++ compiler enables the use of C++
  2679.        classes for Performer types.  Some of these Performer types
  2680.        (pfMatrix, pfVec2, pfVec3, pfVec4, pfQuat) are typedefed
  2681.        arrays when compiling with C and classes when compiling with
  2682.        C++.  Because typedefed arrays and classes differ in their
  2683.        usage, Performer applications written C++ using Performer
  2684.        1.2's C API may not compile under C++ unless Performer is
  2685.        told to revert to C types when compiling under C++.
  2686.  
  2687.        If you wish to compile existing C++ code using Performer C
  2688.        types add the line
  2689.  
  2690.            ''''####ddddeeeeffffiiiinnnneeee PPPPFFFF____CCCCPPPPLLLLUUUUSSSSPPPPLLLLUUUUSSSS____AAAAPPPPIIII 0000''''
  2691.  
  2692.        before including any Performer header files.  Note that the
  2693.        use of C types precludes the use of Performer's C++ API.
  2694.  
  2695.  
  2696.        6.15.1.6  _M_i_x_i_n_g__C_+_+__A_P_I__a_n_d__C__A_P_I__i_n__a__S_i_n_g_l_e__A_p_p_l_i_c_a_t_i_o_n
  2697.  
  2698.        Normally, when compiling under C++, the C API routines
  2699.  
  2700.  
  2701.  
  2702.  
  2703.  
  2704.  
  2705.  
  2706.  
  2707.  
  2708.  
  2709.  
  2710.                                   - 42 -
  2711.  
  2712.  
  2713.  
  2714.        corresponding to member functions on a class are not exposed
  2715.        in the header files.  Applications wishing to taste the
  2716.        combined smorgasbord of both APIs should add the line
  2717.  
  2718.            ''''####ddddeeeeffffiiiinnnneeee PPPPFFFF____CCCC____AAAAPPPPIIII 1111
  2719.  
  2720.        before including any Performer header files.
  2721.  
  2722.  
  2723.        6.15.2  _L_I_B_P_R__E_n_h_a_n_c_e_m_e_n_t_s
  2724.  
  2725.        6.15.2.1  _p_f_G_e_o_S_e_t
  2726.        PFGS_POLYS for N-sided, convex polygons. Specify the number
  2727.        of sides of each polygon with pfGSetPrimLengths().
  2728.  
  2729.        pfGSetPassFilter() sets a filter which allows only specific
  2730.        pfGeoSets to be drawn, e.g., a
  2731.  
  2732.            PPPPFFFFGGGGSSSS____NNNNOOOONNNNTTTTEEEEXXXX____GGGGSSSSEEEETTTT |||| PPPPFFFFGGGGSSSS____EEEEMMMMIIIISSSSSSSSIIIIVVVVEEEE____GGGGSSSSEEEETTTT
  2733.  
  2734.        filter will draw only non-textured, emissive pfGeoSets.
  2735.  
  2736.        pfGetGSetAttrRange() returns the number of attributes (e.g.,
  2737.        coordinates) accessed by non-indexed a pfGeoSet and the
  2738.        maximum range of indexes if the pfGeoSet is indexed.
  2739.  
  2740.        pfGeoSets can now index their pfGeoStates through a global
  2741.        table set by pfApplyGStateTable(). pfGSetGStateIndex() sets
  2742.        the value which is used to index the global table. Indexed
  2743.        pfGeoStates in conjunction with different pfGeoState tables
  2744.        allow drastically different appearances of a single database
  2745.        without duplicating geometry or the scene graph.  For
  2746.        example, a visual and infrared version of a database is
  2747.        easily supported with 2 different pfGeoState tables.
  2748.  
  2749.        pfGeoSets now accept pfCycleBuffer* as attribute lists to
  2750.        support dynamic attribute changes in a pipelined,
  2751.        multiprocessing environment.  pfCycleBuffers automatically
  2752.        manage multiple data buffers to avoid data collisions and
  2753.        ensure frame-accurate behavior of attribute changes.  This
  2754.        greatly simplifies modification of coordinates for
  2755.        sophisticated facial and skeletal animation, geometrically
  2756.        morphed level-of-detail, and special effects such as
  2757.        explosions.  Note that pfCycleBuffer nodes are obsolete with
  2758.        IRIS Performer 2.2 and that pfFlux should be used instead of
  2759.        pfCycleBuffer.
  2760.  
  2761.  
  2762.        6.15.2.2  _p_f_G_e_o_S_t_a_t_e
  2763.        pfGStateFuncs() allow pre and post callbacks on a per-
  2764.        pfGeoState basis.  The pre callback is invoked after the GL
  2765.  
  2766.  
  2767.  
  2768.  
  2769.  
  2770.  
  2771.  
  2772.  
  2773.  
  2774.  
  2775.  
  2776.                                   - 43 -
  2777.  
  2778.  
  2779.  
  2780.        has been configured with the pfGeoState's state and the post
  2781.        callback is lazily invoked by the next pfGeoState
  2782.        application so the pre/post callbacks nicely bracket
  2783.        pfDrawGSet().
  2784.  
  2785.        pfGStateVal() is added for floating point values and now
  2786.        accepts PFSTATE_ALPHAREF.
  2787.  
  2788.        pfGeoSets can now index pfGeoStates (pfGSetGStateIndex())
  2789.        through pfGeoState global tables (pfApplyGStateTable()) or
  2790.        pfGeoState tables assigned to a pfChannel
  2791.        (pfChanGStateTable()) .
  2792.  
  2793.  
  2794.        6.15.2.3  _p_f_F_o_g
  2795.        pfGetFogDensity returns the density of a pfFog at a given
  2796.        range.
  2797.  
  2798.  
  2799.        6.15.2.4  _p_f_L_P_o_i_n_t_S_t_a_t_e
  2800.        A new PFSTATE attribute, pfLPointState causes pfGeoSets of
  2801.        type PFGS_POINTS to be rendered as "light points", e.g.,
  2802.        runway lights, stars. Light points have perspective size
  2803.        based on range and many other features. This is a major
  2804.        enhancement and is discussed in great detail in the
  2805.        pfLPointState man page.
  2806.  
  2807.  
  2808.        6.15.2.5  _p_f_S_p_r_i_t_e
  2809.        A new kind of transform, pfSprite automatically rotates
  2810.        pfGeoSets and plain GL geometry to face the viewer.
  2811.        Different rotational constraints are possible including:
  2812.        rotate about an axis, rotate about a point.
  2813.  
  2814.  
  2815.        6.15.2.6  _p_f_T_e_x_G_e_n
  2816.        A new PFSTATE attribute, pfTexGen encapsulates the GL's
  2817.        texgen() feature which automatically generates texture
  2818.        coordinates. The Wavefront OBJ file loader in libpfdb
  2819.        provides an example of the use of this new capability. Refer
  2820.        to that source code for usage examples.
  2821.  
  2822.  
  2823.        6.15.2.7  _p_f_T_r_a_n_s_p_a_r_e_n_c_y
  2824.        pfTransparency now supports PFTR_MS_ALPHA_MASK which enables
  2825.        multisample transparency but also writes the true alpha
  2826.        value into the frame buffer instead of fully opaque alpha
  2827.        values as PFTR_MS_ALPHA does.
  2828.  
  2829.  
  2830.  
  2831.  
  2832.  
  2833.  
  2834.  
  2835.  
  2836.  
  2837.  
  2838.  
  2839.  
  2840.  
  2841.  
  2842.                                   - 44 -
  2843.  
  2844.  
  2845.  
  2846.        6.15.2.8  _p_f_D_e_c_a_l
  2847.        When using DISPLACE type decals, LAYERS are no longer
  2848.        required to be rendered immediately after their BASES - they
  2849.        can be drawn in any order. This introduces new LAYER-
  2850.        specific tokens:  PFDECAL_LAYER_FAST, PFDECAL_LAYER_DISPLACE
  2851.        and requires specific identification of all layers after the
  2852.        first since each layer must be displaced slightly more than
  2853.        its predecessor.  The tokens PFDECAL_LAYER_1 ->
  2854.        PFDECAL_LAYER_7 are provided for layer identification.
  2855.  
  2856.  
  2857.        6.15.2.9  _p_f_C_y_c_l_e_B_u_f_f_e_r_/_p_f_C_y_c_l_e_M_e_m_o_r_y
  2858.  
  2859.        Note that pfCycleBuffer is obsolete with IRIS Performer2.2
  2860.        in favor of the pfFlux. IRIS Performer 2.0/2.1 pfCycleBuffer
  2861.        are still included in IRIS Performer 2.2.
  2862.  
  2863.        A new kind of pfMemory, pfCycleBuffer supports changing data
  2864.        in a pipelined, multiprocessing environment while
  2865.        maintaining data exclusion and frame-accurate behavior. A
  2866.        pfCycleBuffer manages a set of buffers called pfCycleMemorys
  2867.        and "rotates" them each frame, advancing the data
  2868.        modifications cleanly down the processing pipeline. libpf
  2869.        transparently handles the buffer rotations.
  2870.  
  2871.  
  2872.        6.15.2.10  _p_f_P_o_l_y_t_o_p_e
  2873.        A pfPolytope is a set of N half spaces whose intersection
  2874.        defines a possibly semi-infinite, convex volume which is
  2875.        useful for culling and intersection testing where a tighter
  2876.        bound than a pfSphere, pfBox, pfCylinder, pfFrustum is of
  2877.        benefit.
  2878.  
  2879.  
  2880.        6.15.2.11  _p_f_G_L_O_v_e_r_r_i_d_e
  2881.        Adds the ability to force the use of a particular GL
  2882.        mechanism to implement a libpr feature.
  2883.  
  2884.  
  2885.        6.15.2.12  _p_f_N_o_t_i_f_y
  2886.        pfNotify has been enhanced with new formatting and modes
  2887.        (PFNFY_MORE).  Refer to the pfNotify man page for full
  2888.        details.
  2889.  
  2890.  
  2891.        6.15.2.13  _p_f_G_e_t_T_i_m_e
  2892.        New functions. Refer to the reference pages for further
  2893.        information.
  2894.  
  2895.            ppppffffWWWWrrrraaaappppCCCClllloooocccckkkk
  2896.  
  2897.  
  2898.  
  2899.  
  2900.  
  2901.  
  2902.  
  2903.  
  2904.  
  2905.  
  2906.  
  2907.  
  2908.                                   - 45 -
  2909.  
  2910.  
  2911.  
  2912.            ppppffffCCCClllloooocccckkkkNNNNaaaammmmeeee
  2913.  
  2914.            ppppffffCCCClllloooocccckkkkMMMMooooddddeeee
  2915.  
  2916.        6.15.2.14  _W_i_n_d_o_w__S_y_s_t_e_m__R_o_u_t_i_n_e_s
  2917.        New window-system interface functions provide a single API
  2918.        for creating and managing windows that works across the IRIS
  2919.        GL, IRIS GLX Mixed Mode, and OpenGL-X environments.  Window
  2920.        system independent types have been provided to match the X
  2921.        Window System types to provide complete portability between
  2922.        the IRIS GL and OpenGL-X windowing environments.
  2923.  
  2924.  
  2925.        6.15.2.15  _p_f_Q_u_e_r_y_F_e_a_t_u_r_e_/_p_f_Q_u_e_r_y_S_y_s
  2926.        New QueryFeature routines determine the presence, absence,
  2927.        or limitations of features in the underlying graphics
  2928.        implementation, like the availability of attenuation in the
  2929.        lighting model or the availability of multiple graphics
  2930.        pipes.
  2931.  
  2932.        The QuerySys routines determine the capacity and limitations
  2933.        of the underlying graphics implementation, like the size of
  2934.        texture memory or the number of stencil planes available.
  2935.  
  2936.  
  2937.        6.15.2.16  _p_f_T_e_x_t_u_r_e__e_x_t_e_n_s_i_o_n_s
  2938.  
  2939.        6.15.2.17  _I_n_t_e_g_r_a_t_e_d__T_e_x_t__S_u_p_p_o_r_t
  2940.        Two and Three dimensional font rendering is supported by the
  2941.        new pfFont (libpr), pfString (libpr), and pfText (libpf)
  2942.        primitives.
  2943.  
  2944.        The pfFont facility provides the capability to load fonts
  2945.        for 3-D rendering with the string drawing routines from
  2946.        pfString and pfText.  IRIS Performer uses this facility to
  2947.        provide flat, extruded, and textured-quad fonts in three
  2948.        dimensions.
  2949.  
  2950.        pfString provides a pfGeoSet like facility for encapsulating
  2951.        geometry to display a string in 3-D with attributes such as
  2952.        color, arbitrary transformation matrix, and font (see
  2953.        pfFont).
  2954.  
  2955.        A pfText node is a list of pfStrings much as a pfGeode is a
  2956.        list of pfGeoSets. The two APIs are also similar - a new
  2957.        pfText node can be created and the list of pfStrings
  2958.        attached to it can be manipulated by addition, insertion,
  2959.        removal or replacement.
  2960.  
  2961.        The best examples of these new font tools at present are
  2962.        hello.c and helloC.C, both provided in the IRIS Performer
  2963.  
  2964.  
  2965.  
  2966.  
  2967.  
  2968.  
  2969.  
  2970.  
  2971.  
  2972.  
  2973.  
  2974.                                   - 46 -
  2975.  
  2976.  
  2977.  
  2978.        source directory.
  2979.  
  2980.  
  2981.        6.15.2.18  _p_f_Q_u_a_t
  2982.        A full set of quaternion utilities is defined in prmath.h
  2983.        and is documented in the pfQuat man page.
  2984.  
  2985.  
  2986.        6.15.3  _L_I_B_P_F__E_n_h_a_n_c_e_m_e_n_t_s
  2987.  
  2988.        6.15.3.1  _M_u_l_t_i_p_l_e__W_i_n_d_o_w_s__o_n__a__s_i_n_g_l_e__p_f_P_i_p_e
  2989.  
  2990.        Multiple windows can now be rendered from a single pfPipe.
  2991.        This allows a single drawing process to render to multiple
  2992.        windows on a single screen.  Libpf now requires use of the
  2993.        pfPipeWindow primitive for opening windows for pfPipes.  See
  2994.        the pfWindow and pfPipeWindow (pfConfigPWin()) reference
  2995.        pages for details.
  2996.  
  2997.  
  2998.        6.15.3.2  _p_f_M_o_r_p_h
  2999.  
  3000.        Note that pfMorph node is obsolete in 2.2.  We recommand
  3001.        using pfFlux/pfEngines instead of pfCycleBuffer and pfMorph
  3002.        feature.
  3003.  
  3004.        pfMorph is a new group node intended for automatic morphing
  3005.        of pfGeoSet attributes: colors, normals, coordinates, and
  3006.        texture coordinates but which can morph any floating point
  3007.        values. pfMorph is triggered during the new APP traversal
  3008.        and linearly combines N source arrays into a single
  3009.        destination which is typically a pfCycleBuffer used as a
  3010.        pfGeoSet attribute array.  By modifying the source weights
  3011.        each frame, the application can produce sophisticated,
  3012.        frame-accurate effects such as facial and skeletal animation
  3013.        and morphed, geometric level-of-detail.
  3014.  
  3015.  
  3016.        6.15.3.3  _p_f_D_B_a_s_e
  3017.        The DBASE process is a new addition to the IRIS Performer
  3018.        multiprocessing family. It is similar to the ISECT process
  3019.        in that it can run asynchronously with respect to the main
  3020.        processing pipeline (APP->CULL->DRAW). Callback and trigger
  3021.        functions, pfDBaseFunc() and pfDBase() respectively, allow
  3022.        explicit control and customization of the DBASE function.
  3023.        The DBASE is intended for asynchronous database processing,
  3024.        particularly paging to and from disk when using large
  3025.        databases. Note that IRIS Performer does not provide a
  3026.        paging facility directly - rather it provides the tools
  3027.        which the application can use to implement database paging.
  3028.        Database deletions are carried out in pfDBase() and do not
  3029.  
  3030.  
  3031.  
  3032.  
  3033.  
  3034.  
  3035.  
  3036.  
  3037.  
  3038.  
  3039.  
  3040.                                   - 47 -
  3041.  
  3042.  
  3043.  
  3044.        slow down the synchronous pipeline if DBASE is configured as
  3045.        a separate process.
  3046.  
  3047.  
  3048.        6.15.3.4  _p_f_B_u_f_f_e_r
  3049.        pfBuffer is the primary tool for asynchronous database
  3050.        manipulations. A pfBuffer isolates database changes to a
  3051.        given process, avoiding dangerous data collisions with other
  3052.        processes when multiprocessing.  Scene graphs built in an
  3053.        asynchronous process, such as the DBASE, do not affect the
  3054.        synchronous, real-time APP->CULL->DRAW pipeline and are
  3055.        quickly and safely merged into the main processing stream
  3056.        with pfMergeBuffer().
  3057.  
  3058.  
  3059.        6.15.3.5  _p_f_M_u_l_t_i_t_h_r_e_a_d
  3060.        pfMultithread adds a new multiprocessing dimension by
  3061.        multithreading a given IRIS Performer processing stage.
  3062.        Currently, only the CULL stage may be multithreaded such
  3063.        that thread culls a pfChannel. This is expected to be very
  3064.        useful for MCO applications where many pfChannels per pipe
  3065.        cause the CULL stage to become a bottleneck.
  3066.  
  3067.  
  3068.        6.15.3.6  _P_F_T_R_A_V___A_P_P
  3069.        PFTRAV_APP is a new automated IRIS Performer traversal
  3070.        intended for behavior computation, event distribution and
  3071.        other application level functions. It is carried out in the
  3072.        APP process and is initiated directly by pfAppFrame() or
  3073.        automatically by pfSync(). A wrapper callback and callback
  3074.        data (pfAppFunc(), pfPassAppData()) and node callbacks and
  3075.        data (pfNodeTravFuncs(), pfNodeTravData()) provide
  3076.        application extensibility similar to that offered for the
  3077.        CULL, DRAW, and ISECT traversals.
  3078.  
  3079.  
  3080.        6.15.3.7  _p_f_C_h_a_n_D_a_t_a
  3081.        pfChannel passthrough data may be supplied by the
  3082.        application with pfChanData() rather than allocated by the
  3083.        pfChannel with pfAllocChanData().  This allows pfChannels to
  3084.        share a single passthrough data block.
  3085.  
  3086.  
  3087.        6.15.3.8  _p_f_C_h_a_n_C_u_l_l_P_t_o_p_e
  3088.        pfChanCullPtope() specifies that a pfChannel use a
  3089.        pfPolytope, rather than its viewing pfFrustum, for culling.
  3090.        This allows highly customized culling for specific
  3091.        environments where visibility can be predetermined to some
  3092.        extent, e.g., when in a room and looking through a door the
  3093.        cull volume can be shrunk to the door opening.
  3094.  
  3095.  
  3096.  
  3097.  
  3098.  
  3099.  
  3100.  
  3101.  
  3102.  
  3103.  
  3104.  
  3105.  
  3106.                                   - 48 -
  3107.  
  3108.  
  3109.  
  3110.        6.15.3.9  _p_f_C_h_a_n_N_o_d_e_I_s_e_c_t_S_e_g_s
  3111.        pfChanNodeIsectSegs() is identical to pfNodeIsectSegs() but
  3112.        includes a pfChannel to evaluate pfLODs during the
  3113.        intersection traversal.  Thus, pfChanNodeIsectSegs()
  3114.        computes intersections with the same level-of-detail as is
  3115.        selected for rendering. This greatly simplifies operations
  3116.        such as terrain following on terrain which is modeled as
  3117.        levels-of-detail.
  3118.  
  3119.  
  3120.        6.15.3.10  _p_f_C_h_a_n_G_S_t_a_t_e_T_a_b_l_e
  3121.        pfChannels can provide a pfGeoState table which is accessed
  3122.        by indexed pfGeoSets. This simplifies the management of
  3123.        multiple views of a single database, such as infrared vs.
  3124.        out-the-window.
  3125.  
  3126.  
  3127.        6.15.3.11  _p_f_V_i_d_e_o_R_a_t_e
  3128.        In release 1.2, IRIS Performer internally computed the rate
  3129.        of the video clock.  In 2.0, IRIS Performer now queries the
  3130.        video microcode for the video retrace rate or accepts the
  3131.        rate set by the application with pfVideoRate().
  3132.  
  3133.  
  3134.        6.15.3.12  _p_f_C_o_n_f_i_g_S_t_a_g_e
  3135.        pfStageConfigFunc() allows the specification of an
  3136.        initialization callback for each IRIS Performer processing
  3137.        stage. pfConfigStage() invokes specified initialization
  3138.        callbacks in the appropriate processes at the next
  3139.        pfFrame(). Initialization callbacks typically establish the
  3140.        initial conditions of a process. Examples include setting
  3141.        non-degrading priorities and locking processes to CPUs for
  3142.        real-time applications and downloading textures in the DRAW
  3143.        stage.
  3144.  
  3145.  
  3146.        6.15.3.13  _p_f_L_o_o_k_u_p_N_o_d_e
  3147.        pfLookupNode() extends pfFindNode by searching for a path-
  3148.        named node of a particular type, beginning at a specific
  3149.        node. This greatly simplifies finding named parts of a
  3150.        pfCloned subgraph.
  3151.  
  3152.  
  3153.        6.15.3.14  _p_f_S_c_e_n_e_G_S_t_a_t_e
  3154.        pfScenes can now reference a pfGeoState that defines the
  3155.        "global state" which may be inherited by other pfGeoStates
  3156.        within the scene.
  3157.  
  3158.  
  3159.  
  3160.  
  3161.  
  3162.  
  3163.  
  3164.  
  3165.  
  3166.  
  3167.  
  3168.  
  3169.  
  3170.  
  3171.  
  3172.                                   - 49 -
  3173.  
  3174.  
  3175.  
  3176.        6.15.3.15  _p_f_G_e_t_S_C_S_M_a_t_P_t_r__a_n_d__p_f_G_e_t_D_C_S_M_a_t_P_t_r
  3177.        pfGetDCSMatPtr() returns a pointer to the pfDCS matrix for
  3178.        fast access. Likewise, pfGetSCSMatPtr() returns a pointer to
  3179.        the pfSCS matrix.
  3180.  
  3181.  
  3182.        6.15.3.16  _N_e_w__G_L_-_i_n_d_e_p_e_n_d_e_n_t__W_i_n_d_o_w_i_n_g__U_t_i_l_i_t_i_e_s
  3183.        IRIS Performer now provides utilities for opening, closing,
  3184.        and managing windows.  The same routines will manage pure
  3185.        IRIS GL windows, IRIS GL-X Mixed-Mode, and OpenGL-X windows.
  3186.        Libpf application will now use the new pfPipeWindow for
  3187.        opening IRIS Performer windows.  See the pfWindow (libpr)
  3188.        and pfPipeWindow (libpf) (pfConfigPWin()) reference pages
  3189.        for details.
  3190.  
  3191.  
  3192.        6.15.3.17  _A_P_I__C_h_a_n_g_e_s
  3193.        pfSelectCtab() is now pfApplyCtab()
  3194.        pfGetMallcoSize() is now pfGetSize()
  3195.        pfGetHyperId() is now pfGetPipeHyperId()
  3196.  
  3197.  
  3198.        6.15.3.18  _R_e_f_e_r_e_n_c_e__C_o_u_n_t_i_n_g
  3199.        All pfObjects, including pfNodes now have a reference count.
  3200.        A pfGroup increments the reference count of all its
  3201.        children.
  3202.  
  3203.  
  3204.        6.15.3.19  _M_o_d_e__Q_u_e_r_y__S_e_m_a_n_t_i_c_s
  3205.        pfGetGStateAttr/Mode do not return the global values of
  3206.        inherited state elements. Instead NULL and -1 are returned.
  3207.        Use pfGetCurGStateAttr/Mode for 1.2 behavior.
  3208.  
  3209.  
  3210.        6.15.3.20  _V_i_d_e_o__C_l_o_c_k
  3211.        pfInitVClock() no longer starts and stops the video clock.
  3212.        Instead, use pfStart/StopVClock() to start and stop video
  3213.        interrupts. pfStart/StopVClock are only necessary for
  3214.        VGX/VGXT graphics and are ignored on other graphics.
  3215.  
  3216.  
  3217.        6.15.3.21  _p_f_P_i_p_e_S_c_r_e_e_n
  3218.        Proper multipipe operation now requires that pipes be
  3219.        assigned a screen (pfPipeScreen) before the first pfFrame().
  3220.        Otherwise, pipes will be automatically assigned a screen.
  3221.  
  3222.  
  3223.        6.15.3.22  _p_f_E_v_a_l_u_a_t_e_L_O_D
  3224.        pfEvaluateLOD() returns a floating point number indicating
  3225.        which child is selected by a given pfChannel. The fractional
  3226.        portion of the number is used for fading transitions.
  3227.  
  3228.  
  3229.  
  3230.  
  3231.  
  3232.  
  3233.  
  3234.  
  3235.  
  3236.  
  3237.  
  3238.                                   - 50 -
  3239.  
  3240.  
  3241.  
  3242.        6.15.3.23  _p_f_L_O_D_S_t_a_t_e
  3243.        pfLODStates are used to specify how individual LOD's or
  3244.        groups of LODs will respond to stress and range.
  3245.        pfLODStates can either be explicitly set per LOD or set as
  3246.        an index into a list of pfLODStates provided to a pfChannel.
  3247.        Thus pfLODStates can make the same pfLOD behave differently
  3248.        in different channels as well as differently under different
  3249.        stress conditions.  pfLODStates ultimately modify the range
  3250.        and fade transition calculations made by performer when
  3251.        culling.  See pfLODState, pfLOD, and pfChannel.
  3252.  
  3253.  
  3254.        6.15.3.24  _p_f_L_O_D__e_n_h_a_n_c_e_m_e_n_t_s
  3255.        pfLODs now support per-pair transition zones for fade LOD
  3256.        See the pfLODTransition reference page.
  3257.  
  3258.        pfLODs now respond to stress by scaling LOD ranges and
  3259.        transition zones and take a pfLODState structure to describe
  3260.        the desired stress behavior of a pfLOD. See the pfLODState
  3261.        reference page.
  3262.  
  3263.        LOD Priority Classes can be formed by the sharing of
  3264.        pfLODState structures across a set of LODs.
  3265.  
  3266.        Per-Channel LOD Priority Classes can be formed by assigning
  3267.        pfChannels with tables of pfLODStates and assigning pfLODs
  3268.        an index into these tables. See the pfChanLODAttr and
  3269.        pfLODLODStateIndex reference pages.
  3270.  
  3271.  
  3272.  
  3273.        6.15.4  _l_i_b_p_f_d_u__E_n_h_a_n_c_e_m_e_n_t_s
  3274.  
  3275.        6.15.4.1  _O_p_t_i_m_i_z_i_n_g__S_c_e_n_e__B_u_i_l_d_e_r__f_o_r__u_s_e__i_n__F_i_l_e__L_o_a_d_e_r_s
  3276.        Performer 2.0 contains a new layer of support for easily
  3277.        converting databases from external formats into performer
  3278.        runtime structures.  This new layer is called libpfdu which
  3279.        stands for library of performer database utilities.  The
  3280.        pfdBuilder contains mechanisms for completely converting
  3281.        external database formats and data into efficient IRIS
  3282.        performer structures.  The builder will take care of state
  3283.        sharing and sort your geometry by state.  Collections of
  3284.        graphics state and geometry are given to the pfdBuilder as a
  3285.        database is read in. At the end of reading a database file,
  3286.        a pfNode containing an efficient Performer representation of
  3287.        the database can be obtained.  This new API supersedes the
  3288.        previous pfuBuilder which was a simple interface for
  3289.        encapsulating geometric data into performer structures in an
  3290.        intuitive way.  This new layer of support is built on top of
  3291.        and is a superset of the previous pfuBuilder (which has now
  3292.        become the pfdGeoBuilder) that was released with Performer
  3293.  
  3294.  
  3295.  
  3296.  
  3297.  
  3298.  
  3299.  
  3300.  
  3301.  
  3302.  
  3303.  
  3304.                                   - 51 -
  3305.  
  3306.  
  3307.  
  3308.        1.2.  Check out
  3309.  
  3310.            ////uuuussssrrrr////iiiinnnncccclllluuuuddddeeee////PPPPeeeerrrrffffoooorrrrmmmmeeeerrrr////ppppffffdddduuuu....hhhh
  3311.  
  3312.        for mode settings and api for the new extended builder.
  3313.  
  3314.        libpfdu is the Performer library of database utilities.  Its
  3315.        purpose is to provide helpful functions for constructing
  3316.        optimized Performer data structures and scene graphs.  It is
  3317.        used mainly by database loaders which take an external file
  3318.        format containing 3d geometry and graphics state and load
  3319.        them into Performer optimized run-time only structures.
  3320.        Note that these utilities often prove very useful as most
  3321.        modeling tools and file formats represent their data in
  3322.        structures that correspond to the way users model data and
  3323.        these data structures are often necessarily mutually
  3324.        exclusive with effective and efficient Performer run-time
  3325.        structures.  libpfdu contains many utilities including dso
  3326.        support for database loaders and their modes, file path
  3327.        support, etc, but the heart of libpfdu is the notion of the
  3328.        Performer database 'builder' - pfdBuilder.
  3329.  
  3330.        The builder is a tool to allow users to input/output a
  3331.        collection of geometry and graphics state in immediate mode
  3332.        fashion (similar to Open/Iris GL).  Data is inputed to the
  3333.        builder one geometric primitive at a time along with its
  3334.        corresponding graphics state.  When all of the data has been
  3335.        inputed, the user simply requests optimized Performer data
  3336.        structures which can then be used as a part of a Performer
  3337.        Scene Graph.  The builder hashs geometry into different
  3338.        'bins' based on the geometry's attribute binding types and
  3339.        associated graphics state.  It also keeps track of graphics
  3340.        state elements (textures,materials,light models, fog,etc)
  3341.        and shares state elements whenever possible.  In the end,
  3342.        the builder will create Performer 'pfGeoSets' that contain
  3343.        triangle meshes created by running the original geometry
  3344.        through the libpfdu tmeshing utility.  To go along with each
  3345.        pfGeoSet, the builder builds up a Performer pfGeoState
  3346.        (Performer's encapsulated state primitive) which has been
  3347.        optimized to share as many attributes as possible with other
  3348.        pfGeoStates being build (and possibly even with a more
  3349.        global pfChannelGState).  Having created all of these
  3350.        Performer primitives (pfGeoSets and pfGeoStates) the builder
  3351.        will place them in a Performer leaf node (pfGeode), and
  3352.        possibly even artificially create a spatial hierarchy by
  3353.        running the new database through a spatial breakup utility
  3354.        function which is also contained in libpfdu.  Note that this
  3355.        builder should also allow the user to extend the notion of a
  3356.        'graphics state' by registering callback functionality
  3357.        through builder api and then treating this
  3358.        state/functionality like any other Performer state/mode
  3359.  
  3360.  
  3361.  
  3362.  
  3363.  
  3364.  
  3365.  
  3366.  
  3367.  
  3368.  
  3369.  
  3370.                                   - 52 -
  3371.  
  3372.  
  3373.  
  3374.        (although such uses of the builder are of course at least
  3375.        slightly more complicated).
  3376.  
  3377.        In short libpfdu is a collection of utilities that
  3378.        effectively act as a data funnel where users input flattened
  3379.        3d graphics information and are given in return fully
  3380.        functional and hopefully well optimized Performer run-time
  3381.        structures.
  3382.  
  3383.  
  3384.  
  3385.        6.15.5  _l_i_b_p_f_d_b__E_n_h_a_n_c_e_m_e_n_t_s
  3386.  
  3387.        6.15.5.1  _N_e_w__F_i_l_e__F_o_r_m_a_t_s   OpenInventor 2.0 file support.
  3388.        This is a completely new loader that uses OpenInventor
  3389.        traversal of the input scene graph to create the Performer
  3390.        scene graph, allowing robust conversion of all geometry.
  3391.  
  3392.        AutoDesk 3DStudio file support using the 3dsftk.
  3393.  
  3394.        Side Effects Software Prisms (.poly and .bpoly) file
  3395.        support.
  3396.  
  3397.        Medit Productions Medit (.medit) file support
  3398.  
  3399.        S1000 file support, based on code from Texas Instruments.
  3400.  
  3401.        Several other formats. Look in libpfdb for the complete
  3402.        list.
  3403.  
  3404.  
  3405.        6.15.6  _S_t_r_u_c_t_u_r_a_l__C_h_a_n_g_e_s
  3406.  
  3407.        6.15.6.1  _C_l_a_s_s__s_t_r_u_c_t_u_r_e
  3408.        One of the major differences from 1.2 is that libpr is now
  3409.        written in C++ and the class tree has changed. 1.2 had both
  3410.        a prObject and pfObject - now there is a single pfObject
  3411.        which is derived from IRIS Performer's base class, pfMemory.
  3412.        There are no more pr-prefixed routines which were used for
  3413.        libpr->libpf inheritance, e.g, pfLight -> pfLightSource.
  3414.  
  3415.  
  3416.        6.15.6.2  _p_f_T_y_p_e
  3417.        IRIS Performer has changed its type system to support new,
  3418.        application-derived types. pfGetType() now returns a pfType*
  3419.        instead of a bitmask. Each IRIS Performer data type which
  3420.        has an explicit allocator (usually pfNew*()) has an
  3421.        associated pfType which is created at initialization time by
  3422.        pfInit().  The pfType corresponding to a particular class is
  3423.        returned by pfGet<*>ClassType(), e.g.,
  3424.        pfGetGroupClassType().
  3425.  
  3426.  
  3427.  
  3428.  
  3429.  
  3430.  
  3431.  
  3432.  
  3433.  
  3434.  
  3435.  
  3436.                                   - 53 -
  3437.  
  3438.  
  3439.  
  3440.        The primary difference in 2.0 is the fact that types are no
  3441.        longer represented with bitmasks where the inheritance chain
  3442.        of a particular type is encoded in the bitmask, e.g.,
  3443.        PFTYPE_SCS == (100 | PFCLASS_SCS | PFCLASS_GROUP |
  3444.        PFCLASS_NODE), indicating that SCS is derived from pfGroup
  3445.        and pfNode.  pfType is an opaque data structure whose
  3446.        inheritance chain must be queried through pfIsOfType().
  3447.  
  3448.        Here are the old and new methods for testing an object for
  3449.        exact type equality. The 1.2 method:
  3450.  
  3451.            iiiiffff ((((ppppffffGGGGeeeettttTTTTyyyyppppeeee((((nnnnooooddddeeee)))) ======== PPPPFFFFTTTTYYYYPPPPEEEE____SSSSCCCCSSSS))))
  3452.  
  3453.        and the 2.0 methods, which are equivalent
  3454.  
  3455.            iiiiffff ((((ppppffffGGGGeeeettttTTTTyyyyppppeeee((((nnnnooooddddeeee)))) ======== ppppffffGGGGeeeettttSSSSCCCCSSSSCCCCllllaaaassssssssTTTTyyyyppppeeee(((())))))))
  3456.  
  3457.            iiiiffff ((((ppppffffIIIIssssEEEExxxxaaaaccccttttTTTTyyyyppppeeee((((nnnnooooddddeeee,,,, ppppffffGGGGeeeettttSSSSCCCCSSSSCCCCllllaaaassssssssTTTTyyyyppppeeee(((())))))))))))
  3458.  
  3459.        Here are the old and new methods for testing an object for
  3460.        derivation from a give type. The 1.2 method:
  3461.  
  3462.            iiiiffff ((((ppppffffGGGGeeeettttTTTTyyyyppppeeee((((nnnnooooddddeeee)))) &&&& PPPPFFFFCCCCLLLLAAAASSSSSSSS____GGGGRRRROOOOUUUUPPPP))))
  3463.  
  3464.        and the 2.0 method
  3465.  
  3466.            iiiiffff ((((ppppffffIIIIssssOOOOffffTTTTyyyyppppeeee((((nnnnooooddddeeee,,,, ppppffffGGGGeeeettttGGGGrrrroooouuuuppppCCCCllllaaaassssssssTTTTyyyyppppeeee(((())))))))))))
  3467.  
  3468.        Special care should be taken when porting to the new type
  3469.        API.
  3470.  
  3471.  
  3472.        6.15.7  _C_h_a_n_g_e_s__i_n__l_i_b_p_r
  3473.  
  3474.        6.15.7.1  _D_e_f_a_u_l_t__E_n_a_b_l_e_s
  3475.        PFEN_TEXTURE, PFEN_LIGHTING, PFEN_FOG are no longer enabled
  3476.        by default.  Databases created with loaders that assumed
  3477.        specific global defaults, e.g., pfEnable(PFEN_TEXTURE) will
  3478.        be rendered improperly. All IRIS Performer loaders shipped
  3479.        with 2.0 create pfGeoStates that assume the global default
  3480.        is the same as that set by pfBasicState(), i.e., everything
  3481.        is OFF.
  3482.  
  3483.  
  3484.        6.15.7.2  _L_i_n_e__W_i_d_t_h__a_n_d__P_o_i_n_t__S_i_z_e
  3485.        pfGeoSets with linewidth/pointsize of <= 0 will not set
  3486.        linewidth or pointsize but will inherit it through the GL.
  3487.  
  3488.  
  3489.  
  3490.  
  3491.  
  3492.  
  3493.  
  3494.  
  3495.  
  3496.  
  3497.  
  3498.  
  3499.  
  3500.  
  3501.  
  3502.                                   - 54 -
  3503.  
  3504.  
  3505.  
  3506.        6.15.7.3  _A_l_p_h_a__R_e_f_e_r_e_n_c_e__V_a_l_u_e
  3507.        The PFSTATE_ALPHAREF state element has changed from an
  3508.        integer in the range 0-255 to a float in the range 0-1 and
  3509.        is now set on pfGeoStates with the new routine, pfGStateVal.
  3510.        A warning will be generated if set through pfGStateMode.
  3511.  
  3512.  
  3513.        6.15.7.4  _D_e_c_a_l__I_m_p_l_e_m_e_n_t_a_t_i_o_n
  3514.        pfDecal no longer sets zwritemask to 0 when drawing
  3515.        displaced layers.  This allows layers to be drawn separately
  3516.        from their bases, enabling improved sorting by graphics
  3517.        mode.
  3518.  
  3519.  
  3520.        6.15.7.5  _M_a_t_h__F_u_n_c_t_i_o_n_s
  3521.        pfXformPt3/Vec3 previously considered the last column of the
  3522.        matrix and divided by the homogeneous coordinate, w. The new
  3523.        pfXformPt3/Vec3 are much faster and treats the pfMatrix as a
  3524.        4x3 matrix.  The old behavior is now accessed through the
  3525.        new pfFullXformPt3/Vec3 routines.
  3526.  
  3527.        pfInvertMat is now named pfInvertFullMat but a #define
  3528.        ensures 1.2 compatibility.
  3529.  
  3530.        pfMakeRotOntoMat is obsoleted in favor of the much faster
  3531.        pfMakeVecRotVecMat which assumes normalized input vectors.
  3532.  
  3533.  
  3534.        6.15.7.6  _F_r_u_s_t_u_m__S_p_e_c_i_f_i_c_a_t_i_o_n
  3535.        pfFrustAspect is no longer persistent. In 1.2, automatic
  3536.        frustum calculation (e.g. PFFRUST_CALC_HORIZ) was always in
  3537.        effect once set. In 2.0, pfFrustAspect recomputes the
  3538.        frustum only at time of invocation.
  3539.  
  3540.  
  3541.        6.15.8  _C_h_a_n_g_e_s__i_n__l_i_b_p_f
  3542.  
  3543.        6.15.8.1  _D_e_f_a_u_l_t__E_n_a_b_l_e_s
  3544.        PFEN_TEXTURE, PFEN_LIGHTING, PFEN_FOG are no longer enabled
  3545.        by default.  Databases created with loaders that assumed
  3546.        specific global defaults, e.g., pfEnable(PFEN_TEXTURE) will
  3547.        be rendered improperly. All IRIS Performer loaders shipped
  3548.        with 2.0 create pfGeoStates which assume the global default
  3549.        is the same as that set by pfBasicState(), i.e., everything
  3550.        is OFF. To achieve 1.2 behavior with 1.2 loaders, call the
  3551.        following in the DRAW process after the window is opened:
  3552.  
  3553.            ppppffffEEEEnnnnaaaabbbblllleeee((((PPPPFFFFEEEENNNN____LLLLIIIIGGGGHHHHTTTTIIIINNNNGGGG))));;;;
  3554.  
  3555.            ////**** OOOOnnnnllllyyyy oooonnnn IIIInnnnffffiiiinnnniiiitttteeeeRRRReeeeaaaalllliiiittttyyyy////RRRReeeeaaaalllliiiittttyyyyEEEEnnnnggggiiiinnnneeee////IIIImmmmppppaaaacccctttt////VVVVGGGGXXXXTTTT////VVVVGGGGXXXX ****////
  3556.            ppppffffEEEEnnnnaaaabbbblllleeee((((PPPPFFFFEEEENNNN____TTTTEEEEXXXXTTTTUUUURRRREEEE))));;;;
  3557.  
  3558.  
  3559.  
  3560.  
  3561.  
  3562.  
  3563.  
  3564.  
  3565.  
  3566.  
  3567.  
  3568.                                   - 55 -
  3569.  
  3570.  
  3571.  
  3572.            ppppffffEEEEnnnnaaaabbbblllleeee((((PPPPFFFFEEEENNNN____FFFFOOOOGGGG))));;;;
  3573.  
  3574.        6.15.8.2  _M_u_l_t_i_-_c_h_a_n_n_e_l__f_o_g__a_n_d__l_i_g_h_t_i_n_g__c_o_n_s_i_s_t_e_n_c_y
  3575.        pfChannels now encode rotational offsets (pfChanViewOffsets)
  3576.        in the ModelView instead of the Projection matrix.
  3577.        Consequently, fog always matches across adjacent pfChannels
  3578.        but for proper lighting, a local viewer lighting model is
  3579.        required (pfLModelLocal).
  3580.  
  3581.  
  3582.        6.15.8.3  _T_y_p_e__i_n_h_e_r_i_t_a_n_c_e
  3583.        Multiple inheritance through the C API is gone. Previously,
  3584.        pfChannels could use pfFrustum API, e.g.,
  3585.        pfMakePerspFrust(chan,...) pfFrameStats could use pfStats
  3586.        API, and pfLightSources could use pfLight API, e.g.,
  3587.        pfLightPos(lsource...). Additional routines are now provided
  3588.        to maintain the same functionality without the complexities
  3589.        of multiple inheritance. The new routines name are simply
  3590.        the old routines where the "base" class name is replaced
  3591.        with the "derived" class name. For example, pfMakePerspFrust
  3592.        becomes pfMakePerspChan and pfLightPos becomes pfLSourcePos.
  3593.        Comprehensive tables illustrating the correspondence between
  3594.        routine names are found in pfChannel, pfFrameStats, and
  3595.        pfLightSource man pages.
  3596.  
  3597.  
  3598.        6.15.8.4  _F_r_u_s_t_u_m__S_p_e_c_i_f_i_c_a_t_i_o_n
  3599.        Customizing a viewing frustum with pfMakePerspChan or
  3600.        pfMakeOrthoChan now disables the automatic viewport aspect
  3601.        ratio matching feature of pfChannel (pfChanAutoAspect).
  3602.  
  3603.  
  3604.        6.15.8.5  _A_P_I__C_h_a_n_g_e_s
  3605.        pfChanCullFunc and pfChanDrawFunc are now subsumed by
  3606.        pfChanTravFunc.
  3607.  
  3608.        pfStageConfigFunc() and pfConfigStage() replace the now
  3609.        obsolete pfInitPipe().
  3610.  
  3611.  
  3612.        6.15.8.6  _B_u_g__f_i_x
  3613.        PFPHASE_FLOAT and PFPHASE_LOCK now work in single process
  3614.        mode.
  3615.  
  3616.  
  3617.        6.15.8.7  _p_f_S_w_i_t_c_h__s_e_m_a_n_t_i_c_s
  3618.        pfSwitchVal() used to determine the validity of the switch
  3619.        value which was problematic if no children had been added to
  3620.        the pfSwitch yet. The validity check is now deferred to
  3621.        individual traversal routines.
  3622.  
  3623.  
  3624.  
  3625.  
  3626.  
  3627.  
  3628.  
  3629.  
  3630.  
  3631.  
  3632.  
  3633.  
  3634.                                   - 56 -
  3635.  
  3636.  
  3637.  
  3638.        6.15.8.8  _p_f_D_a_t_a_P_o_o_l_s
  3639.        When Performer shared memory has been created, pfDataPools
  3640.        are now positioned in the virtual address space so that
  3641.        conflicts are less likely to arise.  Such conflicts were a
  3642.        frequent cause of failures of pfAttachDPool.  Deleting a
  3643.        data pool now detaches it from the address space.
  3644.  
  3645.  
  3646.        6.15.8.9  _p_f_P_a_r_t_i_t_i_o_n_s
  3647.        Allow better specification of the spacing and positioning of
  3648.        the spatial partition to reduce construction time. They also
  3649.        work now.
  3650.  
  3651.  
  3652.        6.15.8.10  _O_t_h_e_r__C_h_a_n_g_e_s
  3653.  
  3654.  
  3655.        6.15.8.11  _E_l_i_m_i_n_a_t_i_o_n__o_f__m_u_l_t_i_p_l_e__i_n_h_e_r_i_t_a_n_c_e
  3656.        The CAPI inheritance of pfChannel from pfFrustum,
  3657.        pfLightSource from pfLight and pfFrameStats from pfStats has
  3658.        been removed.  API has been added on the formerly derived to
  3659.        duplicate the functionality of the former base class, e.g.
  3660.        pfApplyFrust(chan) -> pfApplyChan(chan).
  3661.  
  3662.  
  3663.        6.15.8.12  _L_i_g_h_t__M_o_d_e_l__A_t_t_e_n_u_a_t_i_o_n__v_s__L_i_g_h_t__A_t_t_e_n_u_a_t_i_o_n
  3664.        IRIS GL: Light Attenuation is on the pfLightModel
  3665.  
  3666.            vvvvooooiiiidddd ppppffffLLLLMMMMooooddddeeeellllAAAAtttttttteeeennnn((((ppppffffLLLLiiiigggghhhhttttMMMMooooddddeeeellll**** llllmmmm,,,,
  3667.                ffffllllooooaaaatttt aaaa0000,,,, ffffllllooooaaaatttt aaaa1111,,,, ffffllllooooaaaatttt aaaa2222))));;;;
  3668.  
  3669.            vvvvooooiiiidddd ppppffffGGGGeeeettttLLLLMMMMooooddddeeeellllAAAAtttttttteeeennnn((((ppppffffLLLLiiiigggghhhhttttMMMMooooddddeeeellll**** llllmmmm,,,,
  3670.                ffffllllooooaaaatttt**** aaaa0000,,,, ffffllllooooaaaatttt**** aaaa1111,,,, ffffllllooooaaaatttt**** aaaa2222))));;;;
  3671.  
  3672.        OpenGL: Light Attenuation is on the pfLight
  3673.  
  3674.            vvvvooooiiiidddd ppppffffLLLLiiiigggghhhhttttAAAAtttttttteeeennnn((((ppppffffLLLLiiiigggghhhhtttt**** lllltttt,,,,
  3675.                ffffllllooooaaaatttt aaaa0000,,,, ffffllllooooaaaatttt aaaa1111,,,, ffffllllooooaaaatttt aaaa2222))));;;;
  3676.  
  3677.            vvvvooooiiiidddd ppppffffGGGGeeeettttLLLLiiiigggghhhhttttAAAAtttttttteeeennnn((((ppppffffLLLLiiiigggghhhhtttt**** lllltttt,,,,
  3678.                ffffllllooooaaaatttt**** aaaa0000,,,, ffffllllooooaaaatttt**** aaaa1111,,,, ffffllllooooaaaatttt**** aaaa2222))));;;;
  3679.  
  3680.        6.15.8.13  _p_f_A_l_p_h_a_F_u_n_c__n_o_w__t_a_k_e_s__a__f_l_o_a_t__f_o_r__r_e_f
  3681.  
  3682.            wwwwaaaassss:::: vvvvooooiiiidddd ppppffffAAAAllllpppphhhhaaaaFFFFuuuunnnncccc((((iiiinnnntttt rrrreeeeffff,,,, iiiinnnntttt ffffuuuunnnncccc))));;;;
  3683.  
  3684.            nnnneeeewwww:::: vvvvooooiiiidddd ppppffffAAAAllllpppphhhhaaaaFFFFuuuunnnncccc((((ffffllllooooaaaatttt rrrreeeeffff,,,, iiiinnnntttt ffffuuuunnnncccc))));;;;
  3685.  
  3686.        6.15.8.14  _p_f_G_e_t_A_l_p_h_a_F_u_n_c__n_o_w__r_e_t_u_r_n_s__a__f_l_o_a_t__f_o_r__r_e_f
  3687.  
  3688.            wwwwaaaassss:::: vvvvooooiiiidddd ppppffffGGGGeeeettttAAAAllllpppphhhhaaaaFFFFuuuunnnncccc((((iiiinnnntttt ****rrrreeeeffff,,,, iiiinnnntttt ****ffffuuuunnnncccc))));;;;
  3689.  
  3690.  
  3691.  
  3692.  
  3693.  
  3694.  
  3695.  
  3696.  
  3697.  
  3698.  
  3699.  
  3700.                                   - 57 -
  3701.  
  3702.  
  3703.  
  3704.            nnnneeeewwww:::: vvvvooooiiiidddd ppppffffGGGGeeeettttAAAAllllpppphhhhaaaaFFFFuuuunnnncccc((((ffffllllooooaaaatttt ****rrrreeeeffff,,,, iiiinnnntttt ****ffffuuuunnnncccc))));;;;
  3705.  
  3706.        6.15.8.15  _p_f_G_S_t_a_t_e_M_o_d_e__a_n_d__p_f_G_e_t_G_S_t_a_t_e_M_o_d_e
  3707.        pf{Get}GStateMode can no longer accept the PFSTATE_ALPHAREF
  3708.        token.  Use
  3709.  
  3710.            ppppffffGGGGSSSSttttaaaatttteeeeVVVVaaaallll((((ggggssssttttaaaatttteeee,,,, PPPPFFFFSSSSTTTTAAAATTTTEEEE____AAAALLLLPPPPHHHHAAAARRRREEEEFFFF,,,, vvvvaaaallll))));;;;
  3711.  
  3712.        6.15.8.16  _p_f_L_i_g_h_t_C_o_l_o_r__a_n_d__p_f_G_e_t_L_i_g_h_t_C_o_l_o_r
  3713.        pfLightColor and pfGetLightColor now take arguments to
  3714.        specify which color.
  3715.  
  3716.            wwwwaaaassss:::: ppppffffLLLLiiiigggghhhhttttAAAAmmmmbbbbiiiieeeennnntttt aaaannnndddd ppppffffGGGGeeeettttLLLLiiiigggghhhhttttAAAAmmmmbbbbiiiieeeennnntttt aaaarrrreeee oooobbbbssssoooolllleeeetttteeee....
  3717.  
  3718.            nnnneeeewwww:::: vvvvooooiiiidddd ppppffffLLLLiiiigggghhhhttttCCCCoooolllloooorrrr((((ppppffffLLLLiiiigggghhhhtttt**** lllltttt,,,, iiiinnnntttt wwwwhhhhiiiicccchhhh,,,,
  3719.                    ffffllllooooaaaatttt rrrr,,,, ffffllllooooaaaatttt gggg,,,, ffffllllooooaaaatttt bbbb))));;;;
  3720.  
  3721.            nnnneeeewwww:::: vvvvooooiiiidddd ppppffffGGGGeeeettttLLLLiiiigggghhhhttttCCCCoooolllloooorrrr((((ppppffffLLLLiiiigggghhhhtttt**** lllltttt,,,, iiiinnnntttt wwwwhhhhiiiicccchhhh,,,,
  3722.                    ffffllllooooaaaatttt**** rrrr,,,, ffffllllooooaaaatttt**** gggg,,,, ffffllllooooaaaatttt**** bbbb))));;;;
  3723.  
  3724.        6.15.8.17  _p_f_I_n_i_t_G_f_x
  3725.        pfInitGfx() has changed API, location and behavior:
  3726.  
  3727.            wwwwaaaassss:::: vvvvooooiiiidddd ppppffffIIIInnnniiiittttGGGGffffxxxx((((ppppffffPPPPiiiippppeeee ****pppp))));;;;
  3728.  
  3729.            nnnneeeewwww:::: ppppffffIIIInnnniiiittttGGGGffffxxxx((((vvvvooooiiiidddd))));;;;
  3730.  
  3731.        pfInitGfx() should now be used to initialize all pfWindows
  3732.        and pfPipeWindows.
  3733.  
  3734.  
  3735.        6.15.8.18  _p_f_I_n_i_t_G_L_X_G_f_x
  3736.        pfInitGLXGfx(pfPipe *) has been removed. Use the
  3737.        pfPipeWindow utilities.
  3738.  
  3739.  
  3740.        6.15.8.19  _p_f_G_e_t_P_i_p_e_W_i_n__a_n_d__p_f_G_e_t_P_i_p_e_G_L_X_W_i_n_s
  3741.        pfGetPipeWin and pfGetPipeGLXWins have been removed. There
  3742.        is now pfGetPipePWin() to support this functionality.
  3743.  
  3744.  
  3745.        6.15.8.20  _p_f_I_n_i_t_P_i_p_e
  3746.        pfInitPipe() is obsoleted in favor of pfStageConfigFunc()
  3747.        and pfConfigStage().  pfInitPipe() no longer is used to
  3748.        create windows.  Use pfConfigPWin for a window
  3749.        initialization callback.  Use pfConfigStage for initializing
  3750.        (or later re-configuring) the CULL or DRAW processes
  3751.        (stages) for a given pipe.
  3752.  
  3753.  
  3754.  
  3755.  
  3756.  
  3757.  
  3758.  
  3759.  
  3760.  
  3761.  
  3762.  
  3763.  
  3764.  
  3765.  
  3766.                                   - 58 -
  3767.  
  3768.  
  3769.  
  3770.        6.15.8.21  _p_f_G_e_t_P_i_p_e_O_r_i_g_i_n
  3771.        pfGetPipeOrigin() has been removed.  Use pfGetWinOrigin() or
  3772.        pfGetPWinOrigin() to get the size of a pfWindow or
  3773.        pfPipeWindow respectively.
  3774.  
  3775.  
  3776.        6.15.8.22  _p_f_G_e_t_P_i_p_e_S_i_z_e
  3777.        pfGetPipeSize() now returns the screen size of a pfPipe. Use
  3778.        pfGetWinSize() or pfGetPWinSize() to get the size of a
  3779.        pfWindow or pfPipeWindow respectively.
  3780.  
  3781.  
  3782.        6.15.8.23  _p_f_u_W_i_d_g_e_t_F_u_n_c__r_e_n_a_m_e_d
  3783.        pfuWidgetFunc() is now pfuWidgetActionFunc().
  3784.  
  3785.  
  3786.        6.15.8.24  _p_f_u_E_n_a_b_l_e_P_a_n_e_l
  3787.        pfuEnablePanel() no longer takes an enable argument.
  3788.        Instead, pfuPanels are enabled/disabled with
  3789.        pfuEnablePanel() and pfuDisablePanel() respectively.
  3790.  
  3791.  
  3792.        6.15.8.25  _p_f_u_G_e_t_P_a_n_e_l_S_i_z_e
  3793.        pfuGetPanelSize now follows standard convention of (xo, yo,
  3794.        xs, ys) parameter ordering.
  3795.  
  3796.            wwwwaaaassss:::: ppppffffuuuuGGGGeeeettttPPPPaaaannnneeeellllSSSSiiiizzzzeeee((((ppppffffuuuuPPPPaaaannnneeee ****pppp,,,,
  3797.                     iiiinnnntttt ****xxxxoooo,,,, iiiinnnntttt ****xxxxssss,,,, iiiinnnntttt ****yyyyoooo,,,, iiiinnnntttt ****yyyyssss))));;;;
  3798.  
  3799.            nnnneeeewwww:::: ppppffffuuuuGGGGeeeettttPPPPaaaannnneeeellllOOOOrrrrggggSSSSiiiizzzzeeee((((ppppffffuuuuPPPPaaaannnneeee ****pppp,,,,
  3800.                     iiiinnnntttt ****xxxxoooo,,,, iiiinnnntttt ****yyyyoooo,,,, iiiinnnntttt ****xxxxssss,,,, iiiinnnntttt ****yyyyssss))));;;;
  3801.  
  3802.        6.15.8.26  _p_f_I_n_i_t_P_W_i_n
  3803.        pfInitPWin is now pfConfigPWin
  3804.  
  3805.  
  3806.  
  3807.  
  3808.  
  3809.  
  3810.  
  3811.  
  3812.  
  3813.  
  3814.  
  3815.  
  3816.  
  3817.  
  3818.  
  3819.  
  3820.  
  3821.  
  3822.  
  3823.  
  3824.  
  3825.  
  3826.  
  3827.  
  3828.  
  3829.